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-30 21:50:23

On January 30, 2016 1:31:09 PM EST, Noah <duneroadrunner_at_[hidden]> wrote:
> On 1/29/2016 7:00 PM, Rob Stewart wrote:
> >
> > Have a look at boost::intrusive_ptr.
> 
> If I understand boost::intrusive_ptr correctly, and I'm not totally
> sure that I do

You missed, and snipped, the context. You were discussing ways to inject your logic. intrusive_ptr uses free functions, found via ADL, to manage the reference count. That approach could work for you.

> > 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?
> 
> So first let me say that I'm not proposing a total ban on primitive 
> types. When you need the performance, and primitive types give you the
> performance, use them. But that should be small fraction of the
> world's 
> total C++ code.

Okay, but I was asking whether you provide for that case.

> What is antiquated, in my opinion, is that primitive 
> types are the still the default. In terms of not wanting to initialize
> due to subsequent conditional assignment, I would say don't 
> underestimate the compiler optimizer. When the optimizer can figure
> out 
> that the default initialization is redundant, it will remove it for
> you,  right?

You also can't assume that the optimizer will recognize such things.

> I should note though, that I found it difficult (or impossible) to
> fully 
> mimic all the implicit conversion rules of primitive types, so there
> are 
> going to be some cases where the substitute classes can't be used 
> (without rewriting some of your code) for compatibility reasons.

That could prove to be a stumbling block, but you can propose your ideas.

> >> 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?
> 
> I don't know what "marketing narrowing" is, 

I don't either. (Actually, it was my attempt to Swype "narrowing", which was interpreted as "marketing", but I didn't fix it correctly.)

> but recently on this 
> newsgroup people have been discussing a "safe integer" or "safe 
> numerics" library that seems to have taken it all the way, and maybe 
> even a bit further. My types do check ranges when converting to 
> different integer/char types.

That's what I was alluding to.

 > By default, an unsigned integer minus another unsigned integer 
> should really return a signed integer, like my primitives do.

I understand what you're trying to do, but that's a narrowing conversion. The signed type may not be large enough to hold the difference.
___
Rob

(Sent from my portable computation engine)