🚀 go-pugleaf

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote:
> BTW, I compared gcc's __FUNCTION__ with the __func proposal at the ISO C
> site (ftp://ftp.dmk.com/DMK/sc22wg14/c9x/func/func.txt.gz), and I'd
> suggest to copy __FUNCTION__ instead of that from the proposal.
> 
> * __FUNCTION__ is actually a string, so we can use string concatenation:
> 	void foo () { puts ( "Called " __FUNCTION__ "()."); }
>   and so it also ends up in read-only memory, like real strings, despite
>   its non-const* type.  

I agree that this is the most useful design for __FUNC__, but it is 
unfortunately quite incompatible with the phases-of-translation model in
the Standard.  Macros are expanded in translation phase 4, string literals 
get pasted in phase 6, but the implementation doesn't know what function it
is translating until phase 7.

The ways of getting around this dilemma are to either redefine the phases
of translation to allow feedback loops or to define __FUNC__ to be 
something other than a macro.  The sentiment of the Committee is strongly
in favour of not touching Phases of Translation under any circumstances, 
so the second alternative is the one that the Committee decided would be
best to take forward.


> * __FUNCTION__ is defined outside functions (as ""), so macros can
>   safely use it without worrying about how and where they are called.

I think that something like this would make a good amendment to the current
proposal.  I'll take it to the Committee in Nashua.

dave
-- 
Dave Mooney | IBM Toronto Lab | "We see the fish below the ice sometimes."