On Saturday, November 05, 2011 12:08:48 Olaf van der Spek wrote:
On Sat, Nov 5, 2011 at 9:00 AM, Andrey Semashev
Why? What's the benefit over using the default constructor?
I want this for interface consistency which can be useful in generic code and, Do you know existing generic code that'd be affected and couldn't use
<andrey.semashev@gmail.com> wrote: 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.
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. 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?
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 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.