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.

"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.

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.

"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.

"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.

"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 ...

"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.

"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.

> 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

> 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.
>
>