Date: Thu, 04 May 2023 18:48:39 -0700
On Thursday, 4 May 2023 17:54:12 PDT Alejandro Colomar wrote:
> Lambdas are "there be dragons" territory for me :).
I just used lambdas because they are an example of an unnamed type. You can
get the same problem with named ones. C++ allows types to be defined inside any
scope, so you can define two types with the same name inside the same function,
so long as they are in different scopes. I don't have a good use-case for why
you'd do this, but you can.
inline auto f1()
{
struct S { static void f() {} };
return &S::f;
}
inline auto f1()
{
{ struct S { }; }
struct S { static void f() {} };
return &S::f;
}
See https://godbolt.org/z/e7bv7x886
I had to turn off demangling because the demangler is hiding the difference. But
the symbol name changed by the addition of a "_0", which indicates it's the
second type named S found in that function.
BTW, neither MSVC nor the older Intel compiler did that. In the case of ICC,
since it was meant to be ABI-compatible with GCC and Clang on Linux, this is a
bug in the compiler (fortunately, that version is EOL). In the case of MSVC,
it appears to be a conscious decision that the first S did not need an external
name. If you force its hand by creating and using S::f in that first struct, it
does increment the number in the middle of the mangling, the lovely
?f_at_S@?2??f1@@YAXXZ_at_SAXXZ
> Lambdas are "there be dragons" territory for me :).
I just used lambdas because they are an example of an unnamed type. You can
get the same problem with named ones. C++ allows types to be defined inside any
scope, so you can define two types with the same name inside the same function,
so long as they are in different scopes. I don't have a good use-case for why
you'd do this, but you can.
inline auto f1()
{
struct S { static void f() {} };
return &S::f;
}
inline auto f1()
{
{ struct S { }; }
struct S { static void f() {} };
return &S::f;
}
See https://godbolt.org/z/e7bv7x886
I had to turn off demangling because the demangler is hiding the difference. But
the symbol name changed by the addition of a "_0", which indicates it's the
second type named S found in that function.
BTW, neither MSVC nor the older Intel compiler did that. In the case of ICC,
since it was meant to be ABI-compatible with GCC and Clang on Linux, this is a
bug in the compiler (fortunately, that version is EOL). In the case of MSVC,
it appears to be a conscious decision that the first S did not need an external
name. If you force its hand by creating and using S::f in that first struct, it
does increment the number in the middle of the mangling, the lovely
?f_at_S@?2??f1@@YAXXZ_at_SAXXZ
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-05-05 01:48:40