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: Noah (duneroadrunner_at_[hidden])
Date: 2016-02-02 02:25:42

On 2/1/2016 5:47 PM, Rob Stewart wrote:

>> I mean, is the default initialization of std::vector to the empty state
>> no
>> more correct than leaving it uninitialized? Should we require
>> programmers to explicitly set the vector state, even if they want to
>> start off with an empty vector?
>
> That's not what I asked you about. I asked if you provided a way to construct your types without initializing the data. I thought it was obvious that I was asking about a constructor overload taking an instance of, say, uninitialized_t as the mechanism. That is, one would create an instance from an argument named, say, "uninitialized."

Sorry, I'm confused. In this post I was responding to what Steve said. I 
wasn't trying to respond to your question. Although I guess they're related.

And it may be my shortcoming, but it actually wasn't obvious to me that 
you were asking about "a constructor overload taking an instance of, 
say, uninitialized_t as the mechanism". Is that mechanism preferable to 
mechanism of having separate, compatible classes I proposed (in both the 
reply to Steve's post and the reply to your post)? I haven't completely 
thought it through, but I might've thought that solution of having 
separate types might be preferable if only for convenience reasons 
because you wouldn't have to pass any arguments to get an uninitialized 
variable. And, as Steve pointed out, if you choose to use a type that 
requires explicit initialization before use, it may help catch some bugs 
(in debug mode).

But now that you've spelled it out for me, having a single class with a 
separate constructor also seems appealing because then there would 
definitely be no compatibility issues between separate classes. But then 
again, there may be issues other than just default initialization to 
consider. For example, what if we wanted an option to disable run-time 
range checking when converting between different (sized) integer types? 
Keeping the one class and adding an extra constructor for that wouldn't 
really work. Because you'd just be substituting one run-time check for 
another, right? But another separate compatible class might work. And 
how about range checking on arithmetic operations? Is that too many 
options? Should we just not provide for those options?

>
>> Or is the empty state somehow
>> intrinsically valid, but the zero value for integers is not?
>
> Zero may be a valid value with semantics different than "not set." An empty vector doesn't have a magic value that means it's actually empty.

Just to be clear, I wasn't being sarcastic or anything. I'm just trying 
to think this through. So I agree that zero should not be interpreted as 
a "magic" value indicating "value not set". In my reply to Steve I 
suggested that the integer class for example, might, in debug mode, 
contain an extra bool member indicating whether or not the value had 
been explicitly set. And default initialization would set that bool to 
indicate that the value hadn't been explicitly set.

What I am suggesting is that, perhaps, the std::vector people decided 
not to provide for uninitialized vector construction because a) they 
suspected that conditional initialization would be a small portion of 
all initializations and that the default empty state would be a fairly 
large portion, and/or possibly b) the compiler optimizer would deal with 
the redundancy in a significant portion of those conditional 
initializations, and/or c) the cost of the program being 
non-deterministic if a programming error slips by is unacceptably high. 
(I think reason c) is the main one to most of us who desire default 
initialization.) And it's not obvious to me that those reasons don't 
apply to integers as well. With respect to the proportion of all 
initializations that are conditional, the only way we could know that is 
to do a large random sampling of code on github or whatever. I actually 
googled to try and find out if anyone had done such a sampling, because 
I'm actually quite curious what the answer would be. My googling was not 
successful.

I know I'm not always great at expressing my ideas in writing, but if 
you have time to reread my reply to Steve, in it I suggest a solution in 
which three separate compatible classes would be available. Each with a 
different policy for default initialization and requirement for 
"explicit set before use". Do you still prefer the single class with an 
extra constructor for "uninitialized construction" solution to the one I 
proposed?