View mode: basic / threaded / horizontal-split · Log in · Help
March 07, 2005
Re: Do we have __DATE__ ??
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.
March 07, 2005
Re: Do we have __DATE__ ??
"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.
March 07, 2005
Re: Do we have __DATE__ ??
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.
March 07, 2005
Re: Do we have __DATE__ ??
"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.
March 07, 2005
Re: Do we have __DATE__ ??
"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.
March 07, 2005
Re: Do we have __DATE__ ??
"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 ...
March 07, 2005
Re: Do we have __DATE__ ??
"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.
March 07, 2005
Re: Do we have __DATE__ ??
"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.
March 07, 2005
Re: Do we have __DATE__ ?? [OT]
> 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
March 07, 2005
Re: Do we have __DATE__ ??
> 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.
>
>
1 2 3
Top | Discussion index | About this forum | D home