[c++0x] unique_ptr.hpp implementation

[Chris Fairles]

Oops. Sorry for the noise, there should be this:
_Head_base(typename std::remove_reference<_Head>::type && __h) :
_M_head_impl(std::forward<_Head>(__h)) {  }

In the second _Head_base specialization (is_empty == false).

Chris

On 8/17/07, Chris Fairles <chris.fairles@gmail.com> wrote:
> Attached is tuple with EBO (and tuple_cat) along iwth unique_ptr that
> uses it. I modified tuple_size to inherit from
> std::integral_constant<std::size_t, sizeof...(_Elements)> as per
> 20.3.1.3 in N2369.
> make_tuple also takes rvalue ref type and fowards to tuple ctor.
>
> First issue is that I'm not 100% certain when forward is required (vs
> move). I wouldn't mind some clarification on the matter.
>
> Second issue... array types.
> tuple<char[3]> t; tuple<char[3]> u = t;
>
> This fails to compile citing "error: array used as initializer". Is
> the correct solution to somehow collapse the array type to its native
> pointer type ala remove_all_extents<T>::type* ? Or specialize
> everything for arrays?
>
> Chris
>
> On 8/15/07, Howard Hinnant <hhinnant@apple.com> wrote:
> > On Aug 14, 2007, at 5:56 PM, Chris Fairles wrote:
> >
> > > However, EBO only kicks in when theres only one instance of each empty
> > > type int the tuple (i.e. sizeof(tuple<deleter, deleter>) == 2 when I'd
> > > like it to be 1).
> >
> > I believe this is as it has to be.  There's a note in section 10,
> > paragraph 5:
> >
> > > however, two subobjects that have the same class type and that
> > > belong to the same most derived object must not be allocated at the
> > > same address
> >
> > In practice this hasn't been much of a problem.  I haven't run across
> > any use cases where I wanted two potentially zero-sized elements of
> > the same type.
> >
> > -Howard
> >
> >
>
>