unique_ptr constructor which just takes a deleter

[Nevin :-] Liber]

In <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf>
section 20.8.11.2, I noticed that there are no constructors for
unique_ptr which just take a deleter. Is that deliberate and, if so, is
it to avoid a potential problem?

Just curious,

--
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> 773 961-1620

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Howard Hinnant]

On Nov 12, 12:23 pm, "Nevin :-] Liber" <ne...@eviloverlord.com> wrote:
> In <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf>
> section 20.8.11.2, I noticed that there are no constructors for
> unique_ptr which just take a deleter. Is that deliberate and, if so, is
> it to avoid a potential problem?

It was a trade-off between interface complexity and user
functionality. The functionality is still there with:

unique_ptr<A, D> p(nullptr, d);

After I got through with:

unique_ptr(pointer p, implementation-defined d1);
unique_ptr(pointer p, implementation-defined d2);

I was tired and ready to go to bed. ;-) More seriously, the two
overloads above were complicated enough (having to deal with lvalue-
reference deleters and all). And I was not keen to unnecessarily
duplicate that complexity with:

unique_ptr(implementation-defined d1);
unique_ptr(implementation-defined d2);

Additionally since deleters can be pointers, and since unique_ptr's
can point to deleters, I was also not anxious to disambiguate all that
(mistaking a pointer for a deleter or vice-versa). So in the end, it
just didn't seem worth it.

-Howard

--

[Joe Smith]

"Howard Hinnant" <howard....@gmail.com> wrote in message
news:a0b0c382-f613-411b...@e20g2000vbb.googlegroups.com...

>
> On Nov 12, 12:23 pm, "Nevin :-] Liber" <ne...@eviloverlord.com> wrote:
>>
>> In <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2960.pdf>
>> section 20.8.11.2, I noticed that there are no constructors for
>> unique_ptr which just take a deleter. Is that deliberate and, if so, is
>> it to avoid a potential problem?
>
> It was a trade-off between interface complexity and user
> functionality. The functionality is still there with:
>
> unique_ptr<A, D> p(nullptr, d);
>
> After I got through with:
>
> unique_ptr(pointer p, implementation-defined d1);
> unique_ptr(pointer p, implementation-defined d2);
>
> I was tired and ready to go to bed. ;-) More seriously, the two
> overloads above were complicated enough (having to deal with lvalue-
> reference deleters and all).

Speaking of that, the draft standard effectively mandates the
defintion implementions must use there, so implementation-defined is
really just a lazy way to avoid having to give the real expression
here, no? I imagine the full expression using std::remove_reference
and friends is a bit unwieldly.

[Howard Hinnant]

On Nov 15, 1:48 am, "Joe Smith" <unknown_kev_...@hotmail.com> wrote:
> "Howard Hinnant" <howard.hinn...@gmail.com> wrote in message

>
> > unique_ptr(pointer p, implementation-defined d1);
> > unique_ptr(pointer p, implementation-defined d2);
>
> > I was tired and ready to go to bed. ;-) More seriously, the two
> > overloads above were complicated enough (having to deal with lvalue-
> > reference deleters and all).
>
> Speaking of that, the draft standard effectively mandates the
> defintion implementions must use there, so implementation-defined is
> really just a lazy way to avoid having to give the real expression
> here, no? I imagine the full expression using std::remove_reference
> and friends is a bit unwieldly.

Those "implementation-defined" should really be "see below". IIRC
there is an outstanding editorial request on that one. And yes, the
actual implementation is a bit unwieldy. Here is one example
implementation:

unique_ptr(pointer p, typename conditional<
is_reference<deleter_type>::value,
deleter_type,
typename add_lvalue_reference<const
deleter_type>::type
>::type d);
unique_ptr(pointer p, typename remove_reference<deleter_type>::type&&
d);

-Howard