On 3/7/2012 12:57 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 11:01:05 Timon Gehr wrote:
On 03/07/2012 07:05 AM, ixid wrote:
Ah, thank you, so it's wrapping. That seems like a bad idea, what is the
I suspect that the reality of the matter is that if we disallowed implicit
conversions between signed and unsigned, a number of bugs would completely go
away, but others would creep in as a result, and the overal situation wouldn't
necessarily be any better, but I don't know. My initial reaction would be to
agree with you, but there are definitely cases where such an approach would get
annoying and bug-prone (due to the casting involved). But regardless, I really
don't think that you're going to convince Walter on this one, given what he's
said in the past.

- Jonathan M Davis

After writing enough container libraries and whatnot in C++, I always end up going bed while thinking life would be so much easier if implicit signed/unsigned conversions were not allowed.

Then I go to sleep, wake up, and realize how much more horrific the code would be in other places if this was actually true.

The best compromise would probably have been to make size_t signed when migrating to 64 bit memory addressing, and leave the unsigned/signed problems specificaly with size_t values back in the past of 32 bit and older systems.


On a related note I would love to see something in std.somewhere (conv?) to provide a complete set of narrowing and signed/unsigned conversion functions: The matrix is basically the following methods: 1) Reduce size (64->32->16->8 bits) but maintain signedness with three types:
2)  Methods to flip signedness of the value (but mainting bitwidth)


multiplied against three types of operations:
a)  truncating (i.e. mask off the lower bits)
b) saturating (values outside of range are clamped to min or max of the narrower range)
c)  throwing (values outside of narrow range throw a range exception)

Reply via email to