🚀 go-pugleaf

dmm@neutron.torolab.ibm.com (Dave Mooney) writes:
>Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote:
>> * __FUNCTION__ is actually a string, so we can use string concatenation:...
>>   and so it also ends up in read-only memory, like real strings,
>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.

But __FUNCTION__ is not a macro; it is a special construct that is
equivalent to a string constant.  (For example, #ifdef does not work
with __FUNCTION__.)  So there is no problem with phase 4.

And I don't see any problem with phase 6.  String literal pasting can't
possibly change the answer to the question ``what function am I
currently translating?''.  So if the implementation can ``know'' which
function it is translating in phase 7, it can also ``know'' it in phase 6.

Of course, the notion ``the implementation doesn't know what function
it is translating'' is not formally defined in the standard.  Perhaps
this is why I don't understand the objection to __FUNCTION__.

But suppose there turns out to be a problem with __FUNCTION__ and the
existing phases-of-translation model.  Since __FUNCTION__ is the most
useful design, if the phases-of-translation model prohibits it then we
should fix the phases-of-translation model.  We shouldn't adopt a less
useful design simply because our theory is inadequate.  And fixing the
model would be relatively easy.