Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2016-01-29 22:00:56

On January 29, 2016 1:53:54 PM EST, Noah <duneroadrunner_at_[hidden]> wrote:
> On 1/28/2016 5:07 PM, Nat Goodspeed wrote:
> 
> Basically we need a certain function to be 
> called when the target object is destructed and we don't really care
> how 
> it's done. We can add a destructor by deriving a new class from the 
> target class, or we can add a destructor by having the target class be
> derived from a specific class, or frankly, the appropriate code can be
> manually inserted into the existing destructor of the target class. 
> Either way will work. Using the target class as a base class is just
> the "cleanest", least "intrusive" of the options.

Have a look at boost::intrusive_ptr.

> I'm kind of taking a stand on this particular issue, and I
> invite boost, and the wider C++ community to join me. int, unsigned
> int, 
> and the other primitives are a legacy inherited from C. A bad (and 
> unnecessarily dangerous) legacy that needs to be tossed, in my
> opinion. 

[snip]

> The substitutes I provide are such a 
> thin wrapper that I assume any respectable compiler should generate
> the 
> exact same machine code (in release mode) when used as a direct 
> substitute for their native counterparts. But my substitutes are safer
> in that they have default initialization.

Many times I don't want to initialize a variable because the branches in the subsequent code select the value. Do your wrappers provide a constructor that permits leaving the value uninitialized?

> And they also address the bug 
> prone implicit conversion between signed and unsigned ints.

Once you do that, shouldn't you go the rest of the way and check all conversions? For example, what about overflow during marketing narrowing?

___
Rob

(Sent from my portable computation engine)