Jake Ehrlich via llvm-dev
2019-Jun-10 17:15 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
I'm in the same situation James is in and thus have the same bias but I'll +1 that comment nevertheless. I think I prefer using size_t or the uintX_t types where applicable. Only when I need a signed value do I use one. On Mon, Jun 10, 2019, 9:59 AM James Henderson via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Maybe it's just because I work in code around the binary file formats > almost exclusively, but unsigned (or more often uint64_t) is FAR more > common than int everywhere I go. I don't have time right now to read up on > the different links you provided, and I expect this is covered in them, but > it also seems odd to me to use int in a loop when indexing in a container > (something that can't always be avoided), given the types of size() etc. > > On Mon, 10 Jun 2019 at 17:26, Michael Kruse via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Am Sa., 8. Juni 2019 um 13:12 Uhr schrieb Tim Northover via llvm-dev >> <llvm-dev at lists.llvm.org>: >> > I'd prefer us to have something neater than static_cast<int> for the >> > loop problem before we made that change. Perhaps add an ssize (or >> > equivalent) method to all of our internal data structures? They're a >> > lot more common than std::* containers. >> >> +1 >> >> Since C++20 is also introducing ssize [1] members, this makes a lot of >> sense to me. Using it would help avoiding an unsigned comparison as in >> >> if (IndexOfInterestingElement >= Container.size()) >> ... >> >> to sneak in from the start. >> >> Michael >> >> [1] http://wg21.link/p1227r1 >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190610/c2fec688/attachment.html>
Reid Kleckner via llvm-dev
2019-Jun-10 17:29 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
+1 / me too I don't think there's a problem here that needs to be fixed with a coding standard. On Mon, Jun 10, 2019 at 10:16 AM Jake Ehrlich via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I'm in the same situation James is in and thus have the same bias but I'll > +1 that comment nevertheless. I think I prefer using size_t or the uintX_t > types where applicable. Only when I need a signed value do I use one. > > On Mon, Jun 10, 2019, 9:59 AM James Henderson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Maybe it's just because I work in code around the binary file formats >> almost exclusively, but unsigned (or more often uint64_t) is FAR more >> common than int everywhere I go. I don't have time right now to read up on >> the different links you provided, and I expect this is covered in them, but >> it also seems odd to me to use int in a loop when indexing in a container >> (something that can't always be avoided), given the types of size() etc. >> >> On Mon, 10 Jun 2019 at 17:26, Michael Kruse via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Am Sa., 8. Juni 2019 um 13:12 Uhr schrieb Tim Northover via llvm-dev >>> <llvm-dev at lists.llvm.org>: >>> > I'd prefer us to have something neater than static_cast<int> for the >>> > loop problem before we made that change. Perhaps add an ssize (or >>> > equivalent) method to all of our internal data structures? They're a >>> > lot more common than std::* containers. >>> >>> +1 >>> >>> Since C++20 is also introducing ssize [1] members, this makes a lot of >>> sense to me. Using it would help avoiding an unsigned comparison as in >>> >>> if (IndexOfInterestingElement >= Container.size()) >>> ... >>> >>> to sneak in from the start. >>> >>> Michael >>> >>> [1] http://wg21.link/p1227r1 >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190610/8afd73b0/attachment-0001.html>
Aaron Ballman via llvm-dev
2019-Jun-10 17:31 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
On Mon, Jun 10, 2019, 7:16 PM Jake Ehrlich via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I'm in the same situation James is in and thus have the same bias but I'll > +1 that comment nevertheless. I think I prefer using size_t or the uintX_t > types where applicable. Only when I need a signed value do I use one. >+1 to prefering unsigned types. ~Aaron> On Mon, Jun 10, 2019, 9:59 AM James Henderson via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Maybe it's just because I work in code around the binary file formats >> almost exclusively, but unsigned (or more often uint64_t) is FAR more >> common than int everywhere I go. I don't have time right now to read up on >> the different links you provided, and I expect this is covered in them, but >> it also seems odd to me to use int in a loop when indexing in a container >> (something that can't always be avoided), given the types of size() etc. >> >> On Mon, 10 Jun 2019 at 17:26, Michael Kruse via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Am Sa., 8. Juni 2019 um 13:12 Uhr schrieb Tim Northover via llvm-dev >>> <llvm-dev at lists.llvm.org>: >>> > I'd prefer us to have something neater than static_cast<int> for the >>> > loop problem before we made that change. Perhaps add an ssize (or >>> > equivalent) method to all of our internal data structures? They're a >>> > lot more common than std::* containers. >>> >>> +1 >>> >>> Since C++20 is also introducing ssize [1] members, this makes a lot of >>> sense to me. Using it would help avoiding an unsigned comparison as in >>> >>> if (IndexOfInterestingElement >= Container.size()) >>> ... >>> >>> to sneak in from the start. >>> >>> Michael >>> >>> [1] http://wg21.link/p1227r1 >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190610/90024af3/attachment.html>
Mehdi AMINI via llvm-dev
2019-Jun-10 21:03 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
On Mon, Jun 10, 2019 at 10:32 AM Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Mon, Jun 10, 2019, 7:16 PM Jake Ehrlich via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm in the same situation James is in and thus have the same bias but >> I'll +1 that comment nevertheless. I think I prefer using size_t or the >> uintX_t types where applicable. Only when I need a signed value do I use >> one. >> > > +1 to prefering unsigned types. >I'd appreciate if you guys could provide rational that address the extensive arguments and opinion provided in the C++ community that I tried to summarize in the link above. Otherwise I don't know what to take out of unmotivated "+1". -- Mehdi> >> On Mon, Jun 10, 2019, 9:59 AM James Henderson via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Maybe it's just because I work in code around the binary file formats >>> almost exclusively, but unsigned (or more often uint64_t) is FAR more >>> common than int everywhere I go. I don't have time right now to read up on >>> the different links you provided, and I expect this is covered in them, but >>> it also seems odd to me to use int in a loop when indexing in a container >>> (something that can't always be avoided), given the types of size() etc. >>> >>> On Mon, 10 Jun 2019 at 17:26, Michael Kruse via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Am Sa., 8. Juni 2019 um 13:12 Uhr schrieb Tim Northover via llvm-dev >>>> <llvm-dev at lists.llvm.org>: >>>> > I'd prefer us to have something neater than static_cast<int> for the >>>> > loop problem before we made that change. Perhaps add an ssize (or >>>> > equivalent) method to all of our internal data structures? They're a >>>> > lot more common than std::* containers. >>>> >>>> +1 >>>> >>>> Since C++20 is also introducing ssize [1] members, this makes a lot of >>>> sense to me. Using it would help avoiding an unsigned comparison as in >>>> >>>> if (IndexOfInterestingElement >= Container.size()) >>>> ... >>>> >>>> to sneak in from the start. >>>> >>>> Michael >>>> >>>> [1] http://wg21.link/p1227r1 >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190610/f38f64af/attachment.html>