https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #4 from Martin <marmoo1024 at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> N.B. for clang 3.9 the program prints "top level" not the constructor name.
And for __func_ clang 3.9 has has an empty string. Which makes me think clang
3.9 moves the struct to the outside of the function. Which might be good or
bad. __func__ is in the standard, what does the standard say about the proper
scope of __func__ in getter():s(__func__){}.
gcc behaves as if getter was rewritten to
getter() {
s=__func__;
static const char __func__[] = "...";
}
clang 3.8 behaves as if
getter() {
static const char __func__[] = "...";
s=__func__;
}
and clang 3.9 as if the getter inherited __func__ and ___PRETTY_FUNCTION__ from
a different scope.
getter() {
s=__func__;
static const char __func__[] = "...";
}
So, clang 3.9 is doing something like gcc about the order, with something weird
about the scope.
> __PRETTY_FUNCTION__ is a non-standard extension so the standard says nothing
> about how it works. The similar function-local predefined variable __func__
> is standard, and is usable in ctor-init-lists, e.g. this should get the name
> of the constructor:
> I don't see anything in the standard saying the predefined variable __func__
> is not usable in nested classes defined in the block scope where the
> variable is defined.
Yes, it's non-standard, you're right, slipped my mind, but __func__ is
standard, and the two customarily behave alike. And my tests show that they do
behave alike. So the bug could just as well be about __func__. Both behave
differently between compilers. If the standard really doesn't specify, IMHO my
previous comments apply, this is not right, the program should give the same
result regardless of clang, gcc, msvc, or whatever.
