[c++0x] unique_ptr.hpp implementation

[Chris Fairles]

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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unique_ptr.hpp
Type: text/x-c++hdr
Size: 11363 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20070818/f81440aa/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tuple.hpp
Type: text/x-c++hdr
Size: 21488 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20070818/f81440aa/attachment-0001.bin>