[lug] C++ question, without buying expensive doc.s

Paul E Condon pecondon at mesanetworks.net
Mon Jan 10 17:48:56 MST 2005


On Mon, Jan 10, 2005 at 05:14:05PM -0700, Tkil wrote:
> >>>>> "Paul" == Paul E Condon <pecondon at mesanetworks.net> writes:
> 
> Paul> I'm looking for information about predefined names in C++. 
> 
> Out of curiosity, what are you looking for this info for?
> 

There is a predefined in GNU C++ whose name is __FUNCTION__ . This
evaluates to the name of the function that is currently being compiled.
I think this can be used to store the name of a class in the date 
contained in its instances. This is useful for serialize/deserialize.
But I wonder if:
a. is this standards compliant
b. is there some other standards compliant predefine that would be better

I found __FUNCTION__ is some Visual C++ documentation and tried it in
GNU C++ and it worked. Visual C++ also has __TIMESTAMP__ which does not
work in GNU C++. So, this appears to be an area of variability among
compilers. 


> Note that normal compilation modes usually have a huge number of other
> predefined macros (OS, architecture, compiler, etc).  Most compilers
> have listings of what they set, or they can be dumped at runtime.
> 

My experience is that when one finds the section on predefines in the
manual, the docment 'the more important predefined names' and often leave
out some of the ones that are required by the standard.

> Paul> I'm hoping for a link to a place that the responder considers
> Paul> reliable.
> 
> You can get the official C++ spec for about 20$ online; if you're
> going to be doing detailed language-lawyer level stuff, it's well
> worth the investment.  In this particular case, here is the relevant
> bit:
> 
> | 16 Preprocessing directives
> | 
> |   16.8 Predefined macro names [cpp.predefined]
> | 
> |    1 The following macro names shall be defined by the
> |    implementation:
> | 
> |      __LINE__ The line number of the current source line (a
> |               decimal constant).
> | 
> |      __FILE__ The presumed name of the source file (a character
> |               string literal).
> | 
> |      __DATE__ The date of translation of the source file (a
> |               character string literal of the form "Mmm dd yyyy",
> |               where the names of the months are the same as those
> |               generated by the asctime function, and the first
> |               character of dd is a space character if the value is
> |               less than 10). If the date of translation is not
> |               available, an implementationdefined valid date is
> |               supplied.
> | 
> |      __TIME__ The time of translation of the source file (a
> |               character string literal of the form "hh:mm:ss" as in
> |               the time generated by the asctime function). If the
> |               time of translation is not available, an
> |               implementation defined valid time is supplied.
> | 
> |      __STDC__ Whether __STDC__ is predefined and if so, what its
> |               value is, are implementation defined.
> | 
> |      __cplusplus The name __cplusplus is defined to the value
> |                  199711L when compiling a C++ translation unit.
> | 
> |    2 The values of the predefined macros (except for __LINE__ and
> |      __FILE__) remain constant throughout the translation unit.

(A language lawyerly question here: does __TIME__ really not change during
the compilation of a unit for which execution elapsed time of the compiler
is longer than one second? See, I really can be a language lawyer. ;-)

> | 
> |    3 If any of the predefined macro names in this subclause, or the
> |      identifier defined, is the subject of a #define or a #undef
> |      preprocessing directive, the behavior is undefined.
> 
> 

I believe that the GCC people believe that __FUNCTION__ is required, 
but they don't include it in their list of 'more important' predefines.

It's not being a language lawyer. Serialize/deserialize really needs a
linkage (_not_ in the compiler technical sense) from an object back to
its text name, otherwise such linkage must be hand crafted for each
individual object that is to be serialized. 

-- 
Paul E Condon           
pecondon at mesanetworks.net



More information about the LUG mailing list