On Sat, Nov 5, 2011 at 12:38 PM, Andrey Semashev <andrey.semashev@gmail.com> 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