Timur Aydin wrote:
>> I am dearly missing is a macro like __FUNCTION__ that expands to the
>> name of the current function.

Steve Clamage wrote:
> The 1999 C standard has __func__, but it is not a macro. It is
> a predefined static array of const char in every function that
> contains the name of that function. It is not a macro, because
> there is no concept of "function" during the preprocessing phase.
>
> Such a thing could be considered for C++, but there remains the
> question of how to spell the name of a C++ function. Consider:
>
> namespace A { int f(int); }
> namespace B { int f(int); }
> class C { int f(int); int f(int, int); }
> ... etc, with a various kinds of nesting
>
> Should the spelling reflect the scope and/or the parameter list
> and/or the return type? If it reflects types or parameter lists,
> do we expand typedefs, and strip redundant qualifiers? That is:
>
> typedef int I;
> I f(I i) { ... }
> int f(int i) { ... }
> int f(const I i) { ... }
>
> All 3 versions of the function are the same function. Should the
> spelling (assuming parameter lists are included) be the same
> for each version, or should it reflect what the programmer wrote?
>
> A case can be made for many variations of these possibilities,
> including "implementation dependent". These issues need to be
> settled before the feature could be incorporated into C++.

I should point out that deriving a name for a function is similar
to the problem of what name should be returned by typeid(T).name()
for any given type T.

[1]
The obvious choice (which is the one I suggested in the original
proposal) is to use the complete scope and prototype, including
template instantiation parameters, namespaces, and full class
prefixes.  There are other alternatives, of course.  Some other
examples to add to your list:

    namespace NS
    {
        template <class T>
        class Foo
        {
            Foo(int i);
            static void  count();
            T &  bar(int i);

            template <class P>
            class In
            {
                void  baz(P &p, const T &t);
            };
        };
    }

This adds several functions with more complicated names:

    NS::Foo<T>::Foo(int)
    NS::Foo<T>::count
    NS::Foo<T>::bar(int)
    NS::Foo<T>::In<P>::baz(P&,const T&)

Of course, T and P depend entirely on the exact template
instantiation types, which could be quite complicated.

Obviously other examples can be concocted resulting in extremely
long function names; I once calculated the longest function name
that met the largest minimum recommended length limits, with nested
nested namespaces, nested template parameters, and nested inner
classes, could be something like 238,000,000 characters long.

FWIW, I've always thought the '::' token could be shortened to just
':' or '.'.  This could shorten the names somewhat, but at the cost
of producing names different from the C++ source names.  If this
is an acceptable price, we could shorten the names further by
removing redundant punctuation and abbreviating a few keywords,
e.g.:
    "NS:Foo<T:In<P:baz(P&,c T&"
But this is starting to look a lot like name mangling, which is
probably not what most programmers want.

[2]
Another possibility is to provide other predefined identifiers in
addition to __func__ that provide parts of the fully qualified
function name, e.g.:

    __class__       - class/template prefix, "Foo<T>::In<P>"
    __namespace__   - namespace prefix, "NS"
    __args__        - argument prototypes, "P&,const T&"

A fully qualified function name could then be produced by
concatenating all the name pieces together:

    cout << __namespace__  << "::"
        << __class__ << "::"
        << __func__
        << "(" << __args__ << ")";

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Timur Aydin" <taydin@erols.com> writes:

>I have benefitted from the __FILE__ and __LINE__ macros for applications
>that make heavy use of logging (also called tracing, spying). However, what
>I am dearly missing is a macro like __FUNCTION__ that expands to the name of
>the current function. I know that certain compilers have this macro as an
>extension, but I would like to see this macro part of the next C++ standard.
>
>Maybe this question has come up in this newsgroup that often that many
>people are sick and tired of
>seeing this again, but I think if people that agree with me scream and shout
>enough, there is a chance that this will go into the next C++ standard.

The new version of the C standard, C99, has `__func__'.
There is a good chance that this will also go into the next C++ standard,
although the issue is a bit more complicated for C++.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Timur Aydin wrote:
>
> Hello everybody,
>
> I have benefitted from the __FILE__ and __LINE__ macros for applications
> that make heavy use of logging (also called tracing, spying). However, what
> I am dearly missing is a macro like __FUNCTION__ that expands to the name of
> the current function.

The 1999 C standard has __func__, but it is not a macro. It is
a predefined static array of const char in every function that
contains the name of that function. It is not a macro, because
there is no concept of "function" during the preprocessing phase.

Such a thing could be considered for C++, but there remains the
question of how to spell the name of a C++ function. Consider:

namespace A { int f(int); }
namespace B { int f(int); }
class C { int f(int); int f(int, int); }
... etc, with a various kinds of nesting

Should the spelling reflect the scope and/or the parameter list
and/or the return type? If it reflects types or parameter lists,
do we expand typedefs, and strip redundant qualifiers? That is:

typedef int I;
I f(I i) { ... }
int f(int i) { ... }
int f(const I i) { ... }

All 3 versions of the function are the same function. Should the
spelling (assuming parameter lists are included) be the same
for each version, or should it reflect what the programmer wrote?

A case can be made for many variations of these possibilities,
including "implementaion dependent". These issues need to be
settled before the feature could be incorporated into C++.

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Timur Aydin wrote:
>
> Hello everybody,
>
> I have benefitted from the __FILE__ and __LINE__ macros for applications
> that make heavy use of logging (also called tracing, spying). However, what
> I am dearly missing is a macro like __FUNCTION__ that expands to the name of
> the current function. I know that certain compilers have this macro as an
> extension, but I would like to see this macro part of the next C++ standard.
>
> Maybe this question has come up in this newsgroup that often that many
> people are sick and tired of
> seeing this again, but I think if people that agree with me scream and shout
> enough, there is a chance that this will go into the next C++ standard.

There's a basic problem with creating a macro that expands into a
function name; macros are expanded in translation phase 4, but functions
aren't recognised as such until translation phase 7.

However, there is another way to do it. The new C99 standard defines
__func__, with the following rules:

"The identifier _ _func_ _ shall be implicitly declared by the
translator as if, immediately following the opening brace of each
function definition, the declaration

 static const char _ _func_ _[]="function-name";

appeared, where function-name is the name of the lexically-enclosing
function.60)

This name is encoded as if the implicit declaration had been written in
the source character set and then translated into the execution
character set as indicated in translation phase 5."

There's a reasonable that this feature might be included in future
versions of C++, and possibly even as an extension in current
implementations, especially those that use a single compiler to handle
both C99 and C++98.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> namespace A { int f(int); }
> namespace B { int f(int); }
> class C { int f(int); int f(int, int); }
> ... etc, with a various kinds of nesting
>
> Should the spelling reflect the scope and/or the parameter list
> and/or the return type? If it reflects types or parameter lists,
> do we expand typedefs, and strip redundant qualifiers? That is:
>
> typedef int I;
> I f(I i) { ... }
> int f(int i) { ... }
> int f(const I i) { ... }
>
> All 3 versions of the function are the same function. Should the
> spelling (assuming parameter lists are included) be the same
> for each version, or should it reflect what the programmer wrote?

Gcc has __FUNCTION__ for C++ as well.  It gives 'f' for all cases above.

However, there is also a __PRETTY_FUNCTION__, that gives for the cases
above:

int A::f(int)
int B::f(int)
int C::f(int)
int C::f(int, int)
I f(int)
int f(int)
int f(int)

The last is not what I expected for int f(const I i) { ... }.

 Jan D.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jan Dj=E4rv <Jan.Djarv@lu.erisoft.se> writes:

> Steve Clamage wrote:
> >=20
> > namespace A { int f(int); }
> > namespace B { int f(int); }
> > class C { int f(int); int f(int, int); }
> > ... etc, with a various kinds of nesting
> >=20
> > Should the spelling reflect the scope and/or the parameter list
> > and/or the return type? If it reflects types or parameter lists,
> > do we expand typedefs, and strip redundant qualifiers? That is:
> >=20
> > typedef int I;
> > I f(I i) { ... }
> > int f(int i) { ... }
> > int f(const I i) { ... }
> >=20
> > All 3 versions of the function are the same function. Should the
> > spelling (assuming parameter lists are included) be the same
> > for each version, or should it reflect what the programmer wrote?
>=20
> Gcc has __FUNCTION__ for C++ as well.  It gives 'f' for all cases above.
>=20
> However, there is also a __PRETTY_FUNCTION__, that gives for the cases
> above:
>=20
> int A::f(int)
> int B::f(int)
> int C::f(int)
> int C::f(int, int)
> I f(int)
> int f(int)
> int f(int)
>=20
> The last is not what I expected for int f(const I i) { ... }.

Why not? Top-level const does not change the meaning of a prototype;
  f(const int); and f(int); are equivalent prototypes.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <m2wvgimvir.fsf@brownie.frogger.foobar.snot>,
 <llewelly.@@edevnull.dot.com> wrote:
>> The last is not what I expected for int f(const I i) { ... }.
>
>Why not? Top-level const does not change the meaning of a prototype;
>  f(const int); and f(int); are equivalent prototypes.

There is a difference between a prototype declaration
a definition of the function.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"llewelly."@@edevnull.dot.com wrote:
>=20
> Jan Dj=E4rv <Jan.Djarv@lu.erisoft.se> writes:
>=20
> > int f(int)
> >
> > The last is not what I expected for int f(const I i) { ... }.
>=20
> Why not? Top-level const does not change the meaning of a prototype;
>   f(const int); and f(int); are equivalent prototypes.

Yes I know.  I was just surprised that I f(I i) { ... } came out as "I
f(int)".  Why 'I' in the return type and not the arguments?  Similary, I
expected 'I' to come out in int F(const I i).

Just goes to show that there are different expectations.  Some expect a
"what you typed" string, some do not.  I guess that is part of the
reason it has not been standardised yet :-).  Maybe we need three
versions, one function (f), one signature (f(int)) and one what you
typed (I f(I)).=20

 Jan D.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39B7E2B5.9C1DDB2F@sun.com>,
  Steve Clamage <stephen.clamage@sun.com> wrote:
> Timur Aydin wrote:
> >
> > Hello everybody,
> >
> > I have benefitted from the __FILE__ and __LINE__ macros for
applications
> > that make heavy use of logging (also called tracing, spying).
However, what
> > I am dearly missing is a macro like __FUNCTION__ that expands to
the name of
> > the current function.
>
> The 1999 C standard has __func__, but it is not a macro. It is
> a predefined static array of const char in every function that
> contains the name of that function. It is not a macro, because
> there is no concept of "function" during the preprocessing phase.
>
> Such a thing could be considered for C++, but there remains the
> question of how to spell the name of a C++ function. Consider:
>
> namespace A { int f(int); }
> namespace B { int f(int); }
> class C { int f(int); int f(int, int); }
> ... etc, with a various kinds of nesting
>
> Should the spelling reflect the scope

In the Java Native Interface it does, and from experience that's
just an extra source of errors and extreme frustration.  I did this
kind of thing as an experiment, once, to support exception logging
and reporting.  Instead of having the names themselves define the
scope, I had a simple name for each lexical scope (namespace,
class, function) with a pointer to the info for enclosing scope.
It was all supported by a set of very simple classes.

The main problem I ran into was a conflict between static info
and dynamic method invokation: when class B inherited method M from
class A, and M was executed on a B-object, the qualified name
computed from static info was "A::M" whereas "B::M" would be
more relevant & useful for understanding the execution context.

I don't really have a resolution of that problem.  The partial
solution I used was a virtual class name method, but classes should
not have to explicitly support this kind of name info.  And in
particular, requiring a virtual method in every class would break
C compatibility.  So, unsolved problem.  Ideas?


> and/or the parameter list and/or the return type?

It would be no big deal to provide both kinds of name, simple
and adorned.  However, the simple name can always be extracted
from the adorned name.  So perhaps adorned name + std. function?


> If it reflects types or parameter lists,
> do we expand typedefs, and strip redundant qualifiers? That is:
>
> typedef int I;
> I f(I i) { ... }
> int f(int i) { ... }
> int f(const I i) { ... }
>
> All 3 versions of the function are the same function. Should the
> spelling (assuming parameter lists are included) be the same
> for each version, or should it reflect what the programmer wrote?

IMO, a canonical form would be most natural & useful.  The Java
Native Interface shows one way of going about this.  Perhaps
that convention, suitable expanded, could be adopted directly.

Cheers,

- Alf



--
alf_DOT_steinbach_AT_ac_DOT_com (clean the address before replying)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello everybody,

I have benefitted from the __FILE__ and __LINE__ macros for applications
that make heavy use of logging (also called tracing, spying). However, what
I am dearly missing is a macro like __FUNCTION__ that expands to the name of
the current function. I know that certain compilers have this macro as an
extension, but I would like to see this macro part of the next C++ standard.

Maybe this question has come up in this newsgroup that often that many
people are sick and tired of
seeing this again, but I think if people that agree with me scream and shout
enough, there is a chance that this will go into the next C++ standard.

Timur.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]