Hi all, so does anyone know which way this mangling will become? Will it
just use the DT/Dt codes or be collapsed. If we have two ways then it
clearly will not be binary compatible.
We have also noted the following similar case which seems to be
inconsistent.
struct A
{
struct B
{
} b;
}a;
template <class X> auto fn1(X x)->decltype(x) {}
template <class X> auto fn2(X x)->decltype(x) {}
template <class X> auto fn3(X x)->decltype(x.b) {}
template <class X> auto fn4(X &x)->decltype(x) {}
int main()
{
fn1(100); //_Z3fn1IiET_ <-- decltype is folded away
(should it be preserved?)
fn2(a); //_Z3fn2I1AET_ <--
decltype is folded away (should it be preserved?)
fn3(a); //_Z3fn3I1AEDtdtfp_1bET_
fn4(a); //_Z3fn4I1AEDtfp_
}
In these special cases, what is the rationale behind folding away decltype
mangling for dependent types?
As a follow-up, are there special cases where decltype mangling is
preserved for: decltype expressions with non-dependent types,
value-dependent decltype expressions?
Regards, Michael
Rational C/C++ cafe:
http://www.ibm.com/software/rational/cafe/community/ccpp
My Blogs:
Parallel & Multi-Core Computing
http://www.ibm.com/software/rational/cafe/blogs/ccpp-parallel-multicore
C++ Language & Standard
http://www.ibm.com/software/rational/cafe/blogs/cpp-standard
Commercial Computing
http://www.ibm.com/software/rational/cafe/blogs/ccpp-commercial
Boost test results
http://www.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&uid=swg27006911
C/C++ Compilers Support Page
http://www.ibm.com/software/awdtools/ccompilers/support/
C/C++ Feature Request Interface
http://www.ibm.com/support/docview.wss?uid=swg27005811
XL Fortran Compiler Support Page
http://www.ibm.com/software/awdtools/fortran/xlfortran/support/
XL Fortran Feature Request Interface
http://www.ibm.com/support/docview.wss?uid=swg27005812
Michael Wong
XL C++ Compiler kernel Development
IBM Canada Ltd., C2/KD2/8200/MKM
8200 Warden Avenue
Markham, Ontario L6G 1C7
W:905-413-3283 F:905-413-4839
David Vandevoorde <daveed at edg.com> wrote on 06/23/2010 11:29:37 AM:
> [image removed]
>
> Re: [cxx-abi-dev] Decltype mangling and type dependency:
>
> David Vandevoorde
>
> to:
>
> cxx-abi-dev
>
> 06/23/2010 11:33 AM
>
>
> On Jun 22, 2010, at 10:12 PM, Jason Merrill wrote:
>
> > On 06/22/2010 03:34 PM, David Vandevoorde wrote:
> >> I thought we (the C++ committee) deliberately did _not_ put
> access control under SFINAE?
> >
> > Yes, but I think this was a mistake which adds a lot of complexity
> to libraries, as people need to hack around it with cumbersome
> traits. I recently brought this up under "SFINAE and access
> control" on the core reflector.
> >
> >>> > template <class U> decltype (a.i) f() { } // #1
> >>> > template <class U> decltype (b.i) f() { } // #2
> >> This (#2) declaration is invalid because it's a redeclaration of
> #1. (And if they weren't they'd have distinct signatures.)
> >
> > Right, either they're the same function or they have distinct
> signatures. I was arguing that they aren't the same function, so
> they need to have distinct signatures, so we shouldn't fold
> decltype(a.i) to int.
> >
> > But I am leery of trying to define a whole new kind of dependency
> to deal with this, so I guess I'm content to decide that these are
> the same function because a.i is not value-dependent or type-
> dependent--and that these functions wouldn't be subject to the
> hypothetical access-SFINAE because the access doesn't arise from a
> substitution.
>
>
> Thanks: Our reasoning/opinions may differ, but the conclusion is the
> same. So I'll work on wording for that.
>
> Regarding the following case you and Mike Herrick have discussed:
>
> template<class T> auto f(T p)->decltype(p);
>
> The encoding of decltype(p) could use the Dt/DT codes or the
> underlying type (T_). The latter, however, requires a special case
> in the spec: Is it worth it, and if so, where should the line be
> drawn (any identifier with a dependent type? only identifiers with a
> template parameter type? something else?)? (My own preference is
> not to have a special case, but that would require a change in the
> g++ implementation.)
>
> Daveed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20101025/18676abf/attachment.html>