__func__ and C++

[Kai Henningsen]

pkoning@equallogic.com (Paul Koning)  wrote on 03.09.03 in <16214.15622.869677.679859@gargle.gargle.HOWL>:

> >>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:
>
>  Nathan> Joe Buck wrote:
>  >> On Tue, Sep 02, 2003 at 11:24:40AM -0700, Matt Austern wrote:
>  >>
>  >>> Inside a destructor, __func__ and __FUNCTION__ return "foo", not
>  >>> "~foo".  (__PRETTY_FUNCTION__ behaves the way I would expect.)
>  >>>
>  >>> Is this behavior intended, or is it a bug?  The gcc manual merely
>  >>> says that __func__ is supposed to return the function's name
>  >>> without a type signature, and doesn't say what that's supposed to
>  >>> mean in the case of special C++ functions.  Since __func__ in C++
>  >>> is a gcc extension, none of the language standards provide any
>  >>> useful guidance.
>  >>
>  >>
>  >> Reading the document, I would expect "without a type signature" to
>  >> mean that the string does not include the return type or the
>  >> argument types, but I would still expect to see "~foo" rather than
>  >> "foo", or "operator==" or similar.  Of course, since it's an
>  >> extension, it is arbitrary
>  Nathan> should it produce a qualified name? Should it include a
>  Nathan> template-id?  Should it return the mangled name? (Our docs
>  Nathan> rule out the last, but it is what you want in certain places)
>
> That's what PRETTY_FUNC is for.

__PRETTY_FUNC__ is the *un*mangled name.

ISTR that in objc, __FUNCTION__ actually *is* the mangled name - of  
course, objc name mangling is a lot more readable (stuff like  
_i_SomeClass__arg1name_arg2name_ where __PRETTY_FUNCTION__ is "-[SomeClass  
arg1name:arg2name:]").

If this gets defined differently, perhaps there should be a  
__MANGLED_NAME__, too (or however you want to spell it).

MfG Kai