Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: ABI stability of aligned_union et al
Date: Thu, 3 Jul 2008 15:53:31 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A4901E0FC14@exchmail01.Blue.Roguewave.Com>
Thread-Topic: ABI stability of aligned_union et al
Thread-Index: AcjX4JEIeVY4WJGeScG1LMiuBwsQwQFdehYg
References: <4863CB62.3050305@roguewave.com> <48641F89.80000@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

Martin Sebor wrote:
>
>Martin Sebor wrote:
>> The mangling of std::aligned_union depends on support for variadic
>> templates in that specializations of the template will be mangled
>> differently depending on whether _RWSTD_NO_VARIADIC_TEMPLATES is
>> #defined or not. It seems that it should be possible to assure
>> compatible mangling between the two,
>
>After thinking about it some more I no longer believe this is doable.
>With variadic templates the mangled aligned_union will involve only
>the names of the types the template is instantiated on. Without them
>I don't see any way to emulate this unique behavior. I.e., given
>a class template X that takes, say, 2 template arguments, I don't
>see a way to prevent the compiler from including the names of both
>template arguments in the mangled name for the specialization of
>the template on just one argument. The second argument is always
>there, even if it's not actually referenced in code.
>
>So it seems to me that if we provide "workarounds" for the absence
>of support for variadic templates in the compiler there will be no
>way to migrate from a compiler without the feature to one with it
>without breaking the ABI of code that uses templates like
>aligned_union or tuple.

So, I'll ask again. Should we remove the workarounds for missing
variadic template support to avoid any future compatibility issues? This
would essentially remove parts of c++0x until the compiler provided the
necessary support to do it the right way, but I don't really see that as
a bad thing.

Travis

>
>> but I'm not 100% sure, and
>> if it is, that it's worth the effort. There might be other
>> templates where we may not easily be able to achieve compatibility.
>>=20
>> I suppose the big question then is: should we try to fortify the
>> implementation against ABI changes caused by changes in the
>> techniques used in the implementation of C++ 0x? In the past we
>> didn't concern ourselves with this issue but since we can expect
>> compilers to only start supporting some of the new core language
>> features such as variadic templates only slowly and piecemeal,
>> a few at a time, I think it's a concern that we need to address
>> early on.
>>=20
>> Thoughts?
>>=20
>> Martin
>>=20
>
>