Michael Kruse via llvm-dev
2019-Jun-10 16:24 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."
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
James Henderson via llvm-dev
2019-Jun-10 16:58 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."
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190610/edad9af1/attachment.html>
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>
David Greene via llvm-dev
2019-Jun-11 16:58 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."
James Henderson via llvm-dev <llvm-dev at lists.llvm.org> writes:> 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.The reason to use int as an index in loops is for its algebraic properties, which allows some optimizations (vectorization, for example), where unsigned would cause problems. Basically, the optimizer can assume overflow is undefined behavior and optimize accordingly. +10000 for preferring signed unless there's a good reason for unsigned. -David
Possibly Parallel Threads
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."