www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Do we have __DATE__ ??

reply "Matthew" <admin.hat stlsoft.dot.org> writes:
Or __FILE__, __LINE__, etc. etc.?

I really need __DATE__
Mar 07 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 7 Mar 2005 23:07:51 +1100, Matthew wrote:

 Or __FILE__, __LINE__, etc. etc.?
 
 I really need __DATE__
Hear! Hear!. I also would love to have these compiler generated values. They can give meaningful information to people who are trying to find errors happening at a customer's site. It helps narrow down what version they are running and where a run-time message is really coming from. -- Derek Parnell Melbourne, Australia 7/03/2005 11:09:23 PM
Mar 07 2005
next sibling parent novice2 <novice2_member pathlink.com> writes:
I also need __FILE__, __LINE__. __DATE__
Mar 07 2005
prev sibling parent "G.Vidal" <gyvidal wanadoo.fr> writes:
Build can do that, it's exactly the same thing as plugins.
I explained how we could do it in my last post:
http://www.dsource.org/forums/viewtopic.php?t=624



Le Mon, 07 Mar 2005 23:12:14 +1100, Derek Parnell a écrit :

 On Mon, 7 Mar 2005 23:07:51 +1100, Matthew wrote:
 
 Or __FILE__, __LINE__, etc. etc.?
 
 I really need __DATE__
Hear! Hear!. I also would love to have these compiler generated values. They can give meaningful information to people who are trying to find errors happening at a customer's site. It helps narrow down what version they are running and where a run-time message is really coming from.
Mar 07 2005
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Matthew wrote:
 Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
 I really need __DATE__
Date of what? The file's timestamp? When it is compiled? What data type/format would it be? A d_time? (Most sensible for as long as d_time remains the nearest we have to a standard date type.) A string as formatted using std.date.toDateString or std.date.toString? Something else? And do we really want to use reserved identifiers for this? Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 07 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stewart Gordon wrote:

 I really need __DATE__
Date of what? The file's timestamp? When it is compiled?
When it is compiled... http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
 What data type/format would it be?  A d_time?  (Most sensible for as 
 long as d_time remains the nearest we have to a standard date type.)  A 
 string as formatted using std.date.toDateString or std.date.toString? 
 Something else?
Something else: __DATE__ = "Mar 7 2005"; __TIME__ = "15:44:00";
 And do we really want to use reserved identifiers for this?
Well, we *could* use date and time and file and line... It would "silently break" a couple of dozen people's code, but they should be used to that since length ? ;-) --anders
Mar 07 2005
prev sibling next sibling parent reply novice2 <novice2_member pathlink.com> writes:
 Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
It is very usefull! And why "preprocessor"? This is "compiler-predefined constants".
Mar 07 2005
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
novice2 wrote:
Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
It is very usefull!
Would you care to elaborate?
 And why "preprocessor"? This is "compiler-predefined constants".
Because as Walter pointed out somewhere or other, the primary use of __FILE__ and __LINE__ seems to be to create an assert macro. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Mar 07 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d0i0lu$2rhh$1 digitaldaemon.com...
 novice2 wrote:
Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
It is very usefull!
Would you care to elaborate?
 And why "preprocessor"? This is "compiler-predefined constants".
Because as Walter pointed out somewhere or other, the primary use of __FILE__ and __LINE__ seems to be to create an assert macro.
The __DATE__, __TIME__, and __TIMESTAMP__ ones make sense, and I'll add them. The __FILE__ and __LINE__ make less sense, as their usual appearance is in code generating macros (of which assert() is the dominating one). If you used __FILE__ and __LINE__ in a D mixin template, they'll give the file and line of where the template was defined, *not* where the template was instantiated. There's still some utility to that, but not much. But I'll add them in anyway, they don't detract from anything, and people coming from C/C++ really miss them. But I suspect that after a while, they'll be removing them from the source. __FUNCTION__ and __MODULE__ are the wrong way to do things in D. A better way would be to add a general .name property to things, which will give a string with the name in it. g++ goofed with __FUNCTION__ as it prevents the preprocessor from being separated from the compiler.
Mar 07 2005
next sibling parent reply pandemic <pandemic_member pathlink.com> writes:
In article <d0i5rq$5o$1 digitaldaemon.com>, Walter says...
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d0i0lu$2rhh$1 digitaldaemon.com...
 novice2 wrote:
Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
It is very usefull!
Would you care to elaborate?
 And why "preprocessor"? This is "compiler-predefined constants".
Because as Walter pointed out somewhere or other, the primary use of __FILE__ and __LINE__ seems to be to create an assert macro.
The __DATE__, __TIME__, and __TIMESTAMP__ ones make sense, and I'll add them. The __FILE__ and __LINE__ make less sense, as their usual appearance is in code generating macros (of which assert() is the dominating one). If you used __FILE__ and __LINE__ in a D mixin template, they'll give the file and line of where the template was defined, *not* where the template was instantiated. There's still some utility to that, but not much. But I'll add them in anyway, they don't detract from anything, and people coming from C/C++ really miss them. But I suspect that after a while, they'll be removing them from the source.
You've never had the necessity to 'log' output from your code? Glad to hear you're adding these two. BTW: how about considering these as "meta-tags" as has been discussed elsewhere? They could be prescribed in a manner akin to _arguments, _argptr, length -- all prefixed with the "meta-tag" $ symbol? That way, you can avoid all the issues of clashing names. We then have: $arguments $argptr $length $line $file $date $time $timestamp or use the symbol instead? Doesn't this appear to be a cleaner way to handle such things? All those __NAME__ style decorations seem a bit crude, and a bit crufty.
Mar 07 2005
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"pandemic" <pandemic_member pathlink.com> wrote in message
news:d0id7u$8r4$1 digitaldaemon.com...
 In article <d0i5rq$5o$1 digitaldaemon.com>, Walter says...
The __FILE__ and __LINE__ make less sense, as their usual appearance is
in
code generating macros (of which assert() is the dominating one). If you
used __FILE__ and __LINE__ in a D mixin template, they'll give the file
and
line of where the template was defined, *not* where the template was
instantiated. There's still some utility to that, but not much. But I'll
add
them in anyway, they don't detract from anything, and people coming from
C/C++ really miss them. But I suspect that after a while, they'll be
removing them from the source.
You've never had the necessity to 'log' output from your code?
I do it sometimes. But since the __LINE__ isn't coming from macro expansion, I doubt many will write: log(message, __FILE__, __LINE__); But we'll see.
 BTW: how about considering these as "meta-tags" as has been discussed
elsewhere?
 They could be prescribed in a manner akin to _arguments, _argptr,
length -- all
 prefixed with the "meta-tag" $ symbol? That way, you can avoid all the
issues of
 clashing names.

 We then have:

 $arguments
 $argptr
 $length
 $line
 $file
 $date
 $time
 $timestamp

 or use the   symbol instead? Doesn't this appear to be a cleaner way to
handle
 such things? All those __NAME__ style decorations seem a bit crude, and a
bit
 crufty.
That is a pretty good idea. At first glance, it looks better.
Mar 07 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Throughout at least two megabytes or more of code written in PHP (which 
has no macros whatsoever) this is exactly what I do and have instructed 
the developers I lead to do; I have also seen it commonly done in other 
PHP projects.

I'm very glad to see this in D, now, should it stay.  I'm afraid I think 
making the assumption that people won't spell it out (when it's the only 
way to use such an important debugging tool) is a mistake.

Most important, consider a proxying function, such as a function that 
executes a database query, some other long/abstracted process, etc. 
Having the error message/assert come from those line numbers couldn't be 
more useless.

-[Unknown]


 I do it sometimes. But since the __LINE__ isn't coming from macro expansion,
 I doubt many will write:
 
     log(message, __FILE__, __LINE__);
 
 But we'll see.
Mar 08 2005
prev sibling parent "bamb00" <no email.com> writes:
 We then have:

 $arguments
 $argptr
 $length
 $line
 $file
 $date
 $time
 $timestamp

 or use the   symbol instead? Doesn't this appear to be a cleaner way to
handle
 such things? All those __NAME__ style decorations seem a bit crude, and a
bit
 crufty.
Neat idea! I like the $ symbol for it , fits with convention of 'interpolation' in most scripting languages , and looks good :). Charlie "pandemic" <pandemic_member pathlink.com> wrote in message news:d0id7u$8r4$1 digitaldaemon.com...
 In article <d0i5rq$5o$1 digitaldaemon.com>, Walter says...
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d0i0lu$2rhh$1 digitaldaemon.com...
 novice2 wrote:
Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a
macro
preprocessor?
It is very usefull!
Would you care to elaborate?
 And why "preprocessor"? This is "compiler-predefined constants".
Because as Walter pointed out somewhere or other, the primary use of __FILE__ and __LINE__ seems to be to create an assert macro.
The __DATE__, __TIME__, and __TIMESTAMP__ ones make sense, and I'll add them. The __FILE__ and __LINE__ make less sense, as their usual appearance is
in
code generating macros (of which assert() is the dominating one). If you
used __FILE__ and __LINE__ in a D mixin template, they'll give the file
and
line of where the template was defined, *not* where the template was
instantiated. There's still some utility to that, but not much. But I'll
add
them in anyway, they don't detract from anything, and people coming from
C/C++ really miss them. But I suspect that after a while, they'll be
removing them from the source.
You've never had the necessity to 'log' output from your code? Glad to
hear
 you're adding these two.

 BTW: how about considering these as "meta-tags" as has been discussed
elsewhere?
 They could be prescribed in a manner akin to _arguments, _argptr,
length -- all
 prefixed with the "meta-tag" $ symbol? That way, you can avoid all the
issues of
 clashing names.

 We then have:

 $arguments
 $argptr
 $length
 $line
 $file
 $date
 $time
 $timestamp

 or use the   symbol instead? Doesn't this appear to be a cleaner way to
handle
 such things? All those __NAME__ style decorations seem a bit crude, and a
bit
 crufty.
Mar 07 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d0i5rq$5o$1 digitaldaemon.com...
 "Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
 news:d0i0lu$2rhh$1 digitaldaemon.com...
 novice2 wrote:
Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
It is very usefull!
Would you care to elaborate?
 And why "preprocessor"? This is "compiler-predefined constants".
Because as Walter pointed out somewhere or other, the primary use of __FILE__ and __LINE__ seems to be to create an assert macro.
The __DATE__, __TIME__, and __TIMESTAMP__ ones make sense, and I'll add them.
Great.
 The __FILE__ and __LINE__ make less sense, as their usual appearance is in
 code generating macros (of which assert() is the dominating one). If you
 used __FILE__ and __LINE__ in a D mixin template, they'll give the file and
 line of where the template was defined, *not* where the template was
 instantiated. There's still some utility to that, but not much. But I'll add
 them in anyway, they don't detract from anything, and people coming from
 C/C++ really miss them. But I suspect that after a while, they'll be
 removing them from the source.
Great! I'd also ask that we have something like the __BASE_FILE__, which the DMC++ and GCC compilers provide, which represents the main source file/line. I recognise the increased complexity that this would incur when instantiating mixins, but I'm also highly confident that it's not intractable to your cunning. (Nor can I see how it's more complex than the implementation of mixins and foreach, and you did them rather well, no?)
 __FUNCTION__ and __MODULE__ are the wrong way to do things in D. A better
 way would be to add a general .name property to things, which will give a
 string with the name in it. g++ goofed with __FUNCTION__ as it prevents the
 preprocessor from being separated from the compiler.
Agreed.
Mar 07 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d0i0lu$2rhh$1 digitaldaemon.com...
 novice2 wrote:
Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
It is very usefull!
Would you care to elaborate?
 And why "preprocessor"? This is "compiler-predefined constants".
Because as Walter pointed out somewhere or other, the primary use of __FILE__ and __LINE__ seems to be to create an assert macro.
So what?! Just because Walter says one thing that proscribes the universe of possibilities that ingenious minds may create. Bjarne Stroustrup says the one thing anyone can be sure of is that no-one can know of all the possible ways in which C++ may be used. Now some might argue the real possibility of this being a problem with C++, but I guarantee you that D is sufficiently complex for it to apply to it as well. I have, right now, a use for __DATE__. There's been a clear requirement for __FILE__ and __LINE__ for as long as I can remember. Just because Walter states that _he_ doesn't think users should ever get a glimpse of the file and line information associated with a fatal program error - cos more info is always a problem in critical failure conditions, being as how it so hampers the diagnosis of the flaw ... - doesn't make it a universal wisdom. Sigh ...
Mar 07 2005
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Stewart Gordon" <smjg_1998 yahoo.com> wrote in message
news:d0ho99$2hod$1 digitaldaemon.com...
 Matthew wrote:
 Or __FILE__, __LINE__, etc. etc.?
Are these actually that useful in a language that doesn't have a macro preprocessor?
Absolutely!
 I really need __DATE__
Date of what? The file's timestamp? When it is compiled?
Yup!
 What data type/format would it be?  A d_time?  (Most sensible for as long as
d_time remains the nearest we have to a 
 standard date type.)  A string as formatted using std.date.toDateString or
std.date.toString? Something else?
I've currently made it a ulong. So anything that fits in there.
 And do we really want to use reserved identifiers for this?
It's a lot simpler and less likely to dialecticalise (sic.) than using preprocessors.
Mar 07 2005
prev sibling next sibling parent reply Lukas Pinkowski <Lukas.Pinkowski web.de> writes:
Matthew wrote:

 Or __FILE__, __LINE__, etc. etc.?
 
 I really need __DATE__
I'd go further and introduce __FUNC__ which gives us the function name and also __MODULE__, which gives us, right, the module name. This would be really neat, I need some of them, too!
Mar 07 2005
next sibling parent =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
Nice suggestion.

I have added it to my wish list under compiler values.
http://all-technology.com/eigenpolls/dwishlist/

On Mon, 07 Mar 2005 15:33:35 +0100, Lukas Pinkowski wrote:

 Matthew wrote:
 
 Or __FILE__, __LINE__, etc. etc.?
 
 I really need __DATE__
I'd go further and introduce __FUNC__ which gives us the function name and also __MODULE__, which gives us, right, the module name. This would be really neat, I need some of them, too!
Mar 07 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Lukas Pinkowski" <Lukas.Pinkowski web.de> wrote in message
news:d0hoo5$2hp8$1 digitaldaemon.com...
 Matthew wrote:

 Or __FILE__, __LINE__, etc. etc.?

 I really need __DATE__
I'd go further and introduce __FUNC__ which gives us the function name and also __MODULE__, which gives us, right, the module name. This would be really neat, I need some of them, too!
Yes, the thing I'm wanting __DATE__ for would also be much simpler with __MODULE__. I also agree that __FUNC__ should be in there, esp. if Walter facilitates the forwarding of these things in templates and mixins. But even absent that, if people want to use D+preprocessor, these things are really important. For myself, though I'd really like to avoid the preprocessor in D, if we had all these features I would probably write code that'd work well with and without preprocessing, such that one can do builds that will insert them when desirable. Something like: module M; void funcF() { /+ FUNCTION_ +/ . . . } class X { void methodY() { /+ METHOD_ +/ . . . } After all, such things are easy to include in code-generators, and easy to auto insert with Ruby scripts. Even done manually, it's a write once thing. Then one's code will compile with normal D, and with macro expansion, e.g. #define FUNCTION_ +/ std.logging.GroovyLogger.getLogger().LogFunction(__MODULE__, __FUNCTION__, __FILE__, __LINE__); /+ #define METHOD_ +/ std.logging.GroovyLogger.getLogger().LogMethod(__MODULE__, __CLASS__, __FUNCTION__, __FILE__, __LINE__); /+ Frankly, I think such things would be incredibly useful in large projects.
Mar 07 2005
parent xs0 <xs0 xs0.com> writes:
 Then one's code will compile with normal D, and with macro expansion, e.g.
 
 #define    FUNCTION_            +/
std.logging.GroovyLogger.getLogger().LogFunction(__MODULE__, __FUNCTION__,
__FILE__, 
 __LINE__); /+
 
 #define    METHOD_                +/
std.logging.GroovyLogger.getLogger().LogMethod(__MODULE__, __CLASS__,
__FUNCTION__, 
 __FILE__, __LINE__); /+
 
 Frankly, I think such things would be incredibly useful in large projects.
This is a job for AspectD! :) I'm just thinking - if you have a front-end done, how hard is it to implement AOP? It would seem that it's relatively simple, there's "just" pattern matching, code insertion, and some meta-info being made available.. And having debug() and version() with aspects would be just sweet. But I guess supporting AOP at this point in time is not likely to happen? xs0
Mar 07 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

 Or __FILE__, __LINE__, etc. etc.?
 
 I really need __DATE__
But aren't __FILE__, __LINE__, __DATE__, __TIME__ all part of that ancient old preprocessor which is so evil ? ;-) I also find the GCC extension __FUNCTION__ to be useful. Wouldn't it be possible to add these as constants to the lexer, without messing up the language to bad ? Or it could be like an escape sequence or something... But easiest would just be if they were "special" literals. char[] file = __FILE__; int line = __LINE__; char[] date = __DATE__; // "??? ?? ????" char[] time = __TIME__; // "??:??:??" char[] module = __MODULE__; char[] function = __FUNCTION__; Doesn't sound impossible to hack into the DMD front-end... --anders
Mar 07 2005