RE: [boost] shared_ptr doesn't use unsigned reference count?

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?