Off list, the original tuple construction example, i.e.,
#include <tuple>
int main () {
std::tuple<int> t;
std::tuple<int> u (t);
}
will not compile with the GNU libstdc++ tuple implementation either
without the additional `tuple (tuple&)' ctor. That's the main reason I
suggested adding the additional ctor as a workaround.
gcc-4.3.1/include/c++/4.3.1/tuple:
...
227 tuple(const tuple& __in)
228 : _Inherited(static_cast<const _Inherited&>(__in)) { }
229
230 tuple(tuple&& __in)
231 : _Inherited(std::move<_Inherited>(__in)) { }
...
242 // XXX
http://gcc.gnu.org/ml/libstdc++/2008-02/msg00047.html
243 template<typename... _UElements>
244 tuple(tuple<_UElements...>& __in)
245 : _Inherited(static_cast<const _Tuple_impl<0,
_UElements...>&>(__in))
246 { }
Brad.
> -----Original Message-----
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Wednesday, July 02, 2008 3:55 PM
> To: [email protected]
> Subject: Re: error on tuple copy ctor
>
> Eric Lemings wrote:
> >
> >
> >> -----Original Message-----
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of
> Martin Sebor
> >> Sent: Wednesday, July 02, 2008 3:18 PM
> >> To: [email protected]
> >> Subject: Re: error on tuple copy ctor
> >>
> > ...
> >>> Should we add the ctor even if the standard does not
> >> (currently) specify it?
> >>
> >> I don't think it's needed or desirable. In the test case I
> >> posted, we want to call the const T& overload.
> >
> > That's the only workaround I can think of. You have another one in
> > mind?
>
> A workaround for what? This is a valid definition of
> a CopyConstructible and MoveConstructible class (like tuple):
>
> struct S {
> S (const S&);
> S (S&&);
> };
>
> I don't see why S would need another copy ctor with the signature
> of S(S&). I realize tuple is quite a bit more complicated than S,
> too complicated for me to understand why the ctor might be
> necessary if, if fact, it really is. Could you show in a small
> isolated example the problem that this ctor works around?
>
> Martin
>
