Ohhh...now I remember. That's the case that is not currently covered by
the standard. The standard only specifies the following ctor:
tuple (const tuple&);
It does not require this ctor:
tuple (tuple&);
And because of the stricter type checking I mentioned earlier, a
`tuple<int>' value will not bind to a `const tuple<int>&' ctor (which I
really found surprising).
See the following thread from GNU libstdc++ for more info:
http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
Should we add the ctor even if the standard does not (currently) specify
it?
Brad.
> -----Original Message-----
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 12:32 PM
> To: [email protected]
> Subject: error on tuple copy ctor
>
> As a heads up, while playing with the brand spanking new tuple
> I ran into the error below. Looks like some of the ambiguities
> we talked about are still there.
>
> $ cat z.cpp \
> && make CPPOPTS=-D_RWSTD_EXT_CXX_0X CXXOPTS=-std=gnu++0x z
> #include <tuple>
>
> int main () {
> std::tuple<int> t;
> std::tuple<int> u (t);
> }
> gcc -c -I/home/sebor/stdcxx-4.3.x/include/ansi -D_RWSTDDEBUG
> -pthread
> -I/home/sebor/stdcxx-4.3.x/include
> -I/build/sebor/stdcxx-4.3.x-gcc-4.3.0-15D/include
> -I/home/sebor/stdcxx-4.3.x/examples/include -D_RWSTD_EXT_CXX_0X
> -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow
> -Wwrite-strings -Wno-long-long -Wcast-align -std=gnu++0x z.cpp
> /home/sebor/stdcxx-4.3.x/include/rw/_tuple.h: In constructor
> '__rw::__rw_tuple<_HeadT, _TailT ...>::__rw_tuple(_HeadU&&, _TailU&&
> ...) [with _HeadU = std::tuple<int>&, _TailU = , _HeadT =
> int, _TailT = ]':
> /home/sebor/stdcxx-4.3.x/include/tuple:110: instantiated from
> 'std::tuple<_Types>::tuple(_TypesU&& ...) [with _TypesU =
> std::tuple<int>&, _TypesT = int]'
> z.cpp:5: instantiated from here
> /home/sebor/stdcxx-4.3.x/include/rw/_tuple.h:115: error:
> cannot convert
> 'std::tuple<int>' to 'int' in initialization
> make: *** [z.o] Error 1
>
>
