This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __func__ and C++
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 15 Oct 2003 09:03:00 +0200
- Subject: Re: __func__ and C++
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <B7AE02D8-DD72-11D7-8814-000393B2ABA2@apple.com> <20030902174625.A12889@synopsys.com> <3F559B97.70805@codesourcery.com> <16214.15622.869677.679859@gargle.gargle.HOWL>
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