Boost logo

Boost :

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.

(Sent from my portable computation engine)

Boost list run by bdawes at, gregod at, cpdaniel at, john at