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


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

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:nevin@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-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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


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

"Howard Hinnant" <howard.hinnant@gmail.com> wrote in message
news:a0b0c382-f613-411b-b409-1a5810b0efb3@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.

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