This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __func__ and C++
Paul Koning <pkoning@equallogic.com> writes:
| >>>>> "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.
No. __PRETTY_FUNCTION__ includes the types of the function.
| Nathan> IIRC there was a suggestion for some kind of
| Nathan> __QUALIFIED_FUNCTION__ variable.
|
| Nathan> My thoughts are to leave __func__ alone, and wait for some
| Nathan> kind of standarization.
|
| Leaving it alone for the most part makes sense.
The trouble is that without the nested-name-specifier, it is hard to tell
which name we're talking about. Without the nested-name-specifier,
__func__ is pretty useless in C++. It is not a problem in C because C
does not have elaborated notion of scopes.
-- Gaby