[current_function.hpp] fix for Digital Mars
Digital Mars supports __FUNCTION__, __func__ and __PRETTY_FUNCTION__. However the current_function.hpp settings result in "(unknown)" to be used all the time (as __STDC_VERSION__ is hardcoded to 19990L). The Boost code may be appended with ... #elif (defined __DMC__) // since 8.10 # define BOOST_CURRENT_FUNCTION __PRETTY_FUNCTION__ ... The first release supporting __PRETTY_FUNCTION__ was 8.10, at some time before 2002. /Pavel
On Thu, 22 Jun 2006 12:54:06 +0200, "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote:
Digital Mars supports __FUNCTION__, __func__ and __PRETTY_FUNCTION__.
However the current_function.hpp settings result in "(unknown)" to be used all the time (as __STDC_VERSION__ is hardcoded to 19990L).
The Boost code may be appended with
... #elif (defined __DMC__) // since 8.10 # define BOOST_CURRENT_FUNCTION __PRETTY_FUNCTION__ ...
The first release supporting __PRETTY_FUNCTION__ was 8.10, at some time before 2002.
Do you imply that #if defined __PRETTY_FUNCTION__ does not work? --Gennaro.
"Peter Dimov" wrote:
The Boost code may be appended with
... #elif (defined __DMC__) // since 8.10
Shouldn't this be
#if defined( __DMC__ ) && __DMC__ >= 810
or something similar?
Yes, in hex: #if defined( __DMC__ ) && __DMC__ >= 0x810 .... To Gennaro Prota: #ifdef __PRETTY_FUNCTION__ doesn't work, just tried. /Pavel
On Thu, 22 Jun 2006 13:53:51 +0200, "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote:
To Gennaro Prota: #ifdef __PRETTY_FUNCTION__ doesn't work, just tried.
Hmm... who knows... just for my curiosity I've tried on version 8.38n and it works :) Anyway, regardless of the specific case, I find testing for features rather than compilers to be a more robust approach. The latter should be the fallback option. --Gennaro.
On Thu, 22 Jun 2006 13:53:51 +0200, "Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote:
To Gennaro Prota: #ifdef __PRETTY_FUNCTION__ doesn't work, just tried.
If what is said here is true: http://www.digitalmars.com/archives/cplusplus/3997.html then the macro is quite unreliable (like the compiler, anyway). This other page: http://www.digitalmars.com/changelog.html#new848 mentions a bug fix in version 8.44 without telling details. If we were sure it works properly in 8.44+, and that it doesn't with earlier releases, we could only enable it from that version on. --Gennaro.
"Gennaro Prota" wrote:
__PRETTY_FUNCTION__ doesn't work, just tried.
If what is said here is true:
http://www.digitalmars.com/archives/cplusplus/3997.html
then the macro is quite unreliable (like the compiler, anyway). This other page:
__FUNCTION__ looks working. A bug report for __PRETTY_FUNCTION__ has been sent. /Pavel
Pavel Vozenilek wrote:
"Gennaro Prota" wrote:
__PRETTY_FUNCTION__ doesn't work, just tried.
If what is said here is true:
http://www.digitalmars.com/archives/cplusplus/3997.html
then the macro is quite unreliable (like the compiler, anyway). This other page:
__FUNCTION__ looks working. A bug report for __PRETTY_FUNCTION__ has been sent.
What do you mean by "working"? Does __PRETTY_FUNCTION__ not work? 'Cause I already committed your suggestion to enable it. :-) If by "working" you mean that #ifdef works, this is not guaranteed (unless DMC specifically documents it to work, of course). __func__ and equivalents aren't required to be macros. They are required to be "predefined identifiers" that name a character string, not necessarily a literal. C99 says: 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.
"Peter Dimov" wrote:
A bug report for __PRETTY_FUNCTION__ has been sent.
What do you mean by "working"? Does __PRETTY_FUNCTION__ not work? 'Cause I already committed your suggestion to enable it. :-)
http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/5178 It is the smallest of existing problems. The current (8.49.1) version of DMC is not yet fit for Boost. I got quite a high hope for near future because: * DMC propgress is quite visible (year ago almost nothing in Boost had compiled) * finally a useable STLport had appeared (5.10, beta few days ago - previous versions were less than good) * I am not alone in trying the Boost compatibility * the patches are released frequently /Pavel
Pavel Vozenilek wrote:
"Peter Dimov" wrote:
A bug report for __PRETTY_FUNCTION__ has been sent.
What do you mean by "working"? Does __PRETTY_FUNCTION__ not work? 'Cause I already committed your suggestion to enable it. :-)
http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/5178
It is the smallest of existing problems.
So what do you suggest we do with current_function.hpp? Use __FUNCTION__ instead?
"Peter Dimov" wrote:
http://www.digitalmars.com/drn-bin/wwwnews?c%2B%2B/5178
It is the smallest of existing problems.
So what do you suggest we do with current_function.hpp? Use __FUNCTION__ instead?
Keep the __PRETTY_FUNCTION__. No one uses DMC with Boost now and this is the easiest bug to be fixed. /Pavel
participants (3)
-
Gennaro Prota -
Pavel Vozenilek -
Peter Dimov