Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor

Subject: Re: [boost] [smart_ptr] scoped_array / shared_array (size_t) constructor
From: Olaf van der Spek (ml_at_[hidden])
Date: 2011-11-05 12:16:30

On Sat, Nov 5, 2011 at 12:38 PM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
>> Do you know existing generic code that'd be affected and couldn't use
>> the default constructor?
>
> I probably know the code that will be affected. Although I can't remember if
> it can be converted to default constructor (I don't have the code at hand, but
> it's probably possible). Either way, that doesn't change my mind. Allocating
> things is not smart pointers' business and I'd like to keep it that way.

What principle/rule says it should be done out-of-class? STL
containers like string and vector do their own allocation.

>> > well, is the expected behavior. Every smart pointer tries to mimic raw
>> > pointers and the constructor ambiguity reduces this similarity. I also
>> > don't want to update my code when it breaks.
>>
>> What's the problem with updating your code?
>
> I don't want to waste my time. I'm sure there will be others who aren't aware
> of this conversation and will be puzzled to discover that boost smart pointers
> can't be constructed from NULL.

I've never used (NULL) with a smart ptr. Why would you do that? Would
be nice to see some real code that does that.

> Honestly, can you give me a single reason why e.g. scoped_array can't be
> initialized with NULL? And why are you so eager to break the interface?

Code simplicity

  // typedef boost::shared_array<unsigned char> shared_data;
1. shared_data d0(256);
2. BOOST_AUTO(d1, make_shared_data(256));
3. auto d2 = make_shared_data(256);

2 is much more verbose than 1, 3 is also more verbose than 1

I'd love to not break (NULL) and (0), but I'd also love to have simple code.

>> Also, could you address how you'd implement this in C++03?
>
> What exactly? Moveability and make_scoped_array? Sure, take a look at
> boost::thread, it supports moving in C++03. With shared_array movability is

Thanks, I'll take a look.

> even not required. Auto? BOOST_AUTO has already been mentioned. Yes, it won't
> help members. That's ok with me since I don't remember a single time when I
> had to use scoped_array as a member. Shared_array is more probable as a
> member, but I'm ok with it either. And my previous suggesion about named
> arguments to the constructor is also 100% doable in C++03. I would still
> prefer make_* functions though.

The named parameter is possible but unfortunately also more complex.

-- 
Olaf