From: Michael VanLoon (MichaelV_at_[hidden])
Date: 2001-10-24 18:01:39
You forgot one very important reason: ease of sanity-checking.
With a signed number, you can check against "count < 0" in debug code.
Attach an assert to it and you have some very nice sanity checking.
> From: Darin Adler [mailto:darin_at_[hidden]]
> Sent: Tuesday, October 23, 2001 10:21 PM
> on 10/23/01 5:14 PM, jeremy_at_[hidden] at jeremy_at_[hidden] wrote:
> > Can anyone tell me why shared_ptr's pn member is not unsigned?
> I'm aware of three reasons to use an unsigned long rather
> than a long in a C
> or C++ program:
> 1) to get predictable behavior from overflows and shifts
> 2) to get an extra bit to accommodate larger numbers
> 3) for clarity, when the value is always non-negative
> In the case of shared_ptr, reason 1 does not apply. The 2^31
> values that are
> guaranteed by the C standard in a long are more than enough
> and 2^32 would
> not be better, so reason 2 does not apply.
> That leaves us with reason 3, clarity.
> Many C and C++ programmers prefer to avoid the pitfalls of unsigned
> arithmetic -- having the edge of the numeric range right next
> to 0 makes it
> easier to write incorrect code. These programmers don't
> consider clarity
> reason enough to use an unsigned type, and only use an
> unsigned integer type
> when either reason 1 or 2 applies.
> Let me turn your question around.
> Can anyone tell me a practical advantage that would result from making
> shared_ptr's pn member be unsigned?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk