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