That's cool, but how about being able to print the current line number and source file using #line and #file or equivalent? Perhaps treat them as char[], so you can do something like printf ("file %.*s, line %.*s\n", #file, #line) ?

Why would one wish to do that, you ask? Well, it's really very useful for a remote-logger to indicate which file a log-event was generated from, and even more so when it tells you the source line number. Currently there's no reasonable way for mango.log to produce that kind of information as it spits out log events to the Chainsaw console ...



"Walter" <newshound@digitalmars.com> wrote in message news:cd02p5$1vj6$1@digitaldaemon.com...
>
> "Andy Friesen" <andy@ikagames.com> wrote in message news:ccvvum$1pi6$1@digitaldaemon.com...
> > Matthew Wilson wrote:
> >
> > > What do we think of supporting #line?
> >
> > The only use for it I can think of is for tricking the compiler into outputting 'correct' line numbers and filenames in error messages when compiling code that is the output of some preprocessor.
> >
> > If D even needs it, shouldn't it be a pragma?
>
> The #line is there in D so that D can handle the output of the C preprocessor.
>
>

I don't see what's wrong with __FILE__ and __LINE__.

Ruby does this.


"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cd0a9m$2drd$1@digitaldaemon.com...
> That's cool, but how about being able to print the current line number and source file using #line and #file or equivalent? Perhaps treat them as char[], so you can do something like printf ("file %.*s, line %.*s\n", #file, #line) ?
>
> Why would one wish to do that, you ask? Well, it's really very useful for
a
> remote-logger to indicate which file a log-event was generated from, and even more so when it tells you the source line number. Currently there's
no
> reasonable way for mango.log to produce that kind of information as it
spits
> out log events to the Chainsaw console ...
>
>
>
> "Walter" <newshound@digitalmars.com> wrote in message news:cd02p5$1vj6$1@digitaldaemon.com...
> >
> > "Andy Friesen" <andy@ikagames.com> wrote in message news:ccvvum$1pi6$1@digitaldaemon.com...
> > > Matthew Wilson wrote:
> > >
> > > > What do we think of supporting #line?
> > >
> > > The only use for it I can think of is for tricking the compiler into outputting 'correct' line numbers and filenames in error messages when compiling code that is the output of some preprocessor.
> > >
> > > If D even needs it, shouldn't it be a pragma?
> >
> > The #line is there in D so that D can handle the output of the C preprocessor.
> >
> >
>
>

Can't say that I particularly care what they're called; I just want the functionality :-)


"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:cd0alo$2eeg$1@digitaldaemon.com...
> I don't see what's wrong with __FILE__ and __LINE__.
>
> Ruby does this.
>
>
> "Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message news:cd0a9m$2drd$1@digitaldaemon.com...
> > That's cool, but how about being able to print the current line number
and
> > source file using #line and #file or equivalent? Perhaps treat them as char[], so you can do something like printf ("file %.*s, line %.*s\n", #file, #line) ?
> >
> > Why would one wish to do that, you ask? Well, it's really very useful
for
> a
> > remote-logger to indicate which file a log-event was generated from, and even more so when it tells you the source line number. Currently there's
> no
> > reasonable way for mango.log to produce that kind of information as it
> spits
> > out log events to the Chainsaw console ...
> >
> >
> >
> > "Walter" <newshound@digitalmars.com> wrote in message news:cd02p5$1vj6$1@digitaldaemon.com...
> > >
> > > "Andy Friesen" <andy@ikagames.com> wrote in message news:ccvvum$1pi6$1@digitaldaemon.com...
> > > > Matthew Wilson wrote:
> > > >
> > > > > What do we think of supporting #line?
> > > >
> > > > The only use for it I can think of is for tricking the compiler into outputting 'correct' line numbers and filenames in error messages
when
> > > > compiling code that is the output of some preprocessor.
> > > >
> > > > If D even needs it, shouldn't it be a pragma?
> > >
> > > The #line is there in D so that D can handle the output of the C preprocessor.
> > >
> > >
> >
> >
>
>

In article <cd0bjn$2g99$1@digitaldaemon.com>, Kris says...
>
>Can't say that I particularly care what they're called; I just want the functionality :-)

You can get it, if you're prepared to live with an ugly hack (and one which D
was trying to avoid).

You can tweak your makefile or build script so that your D source is pushed through a C++ preprocessor before it hits the D compiler. __FILE__ and __LINE__ will then be expanded by the preprocessor, and subsequently seen as compile-time constants by DMD.

If D /really/ wants to make the preprocessor redundant, it will have to provide that functionality for itself.

Arcane Jill

Matthew Wilson wrote:

> I don't see what's wrong with __FILE__ and __LINE__.
> 
> Ruby does this.
<snip top of upside-down reply>

Aren't identifiers beginning with __ meant to be implementation specific?  (Or am I thinking of C(++)?)  If we're going to support it, is there a reason against having it in the standard?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Walter wrote:
> "Andy Friesen" <andy@ikagames.com> wrote in message
> news:ccvvum$1pi6$1@digitaldaemon.com...
<snip>
>> If D even needs it, shouldn't it be a pragma?
> 
> The #line is there in D so that D can handle the output of the C
> preprocessor.

For people who've found an inadequacy in D's replacement features, and so decide to run their code through the preprocessor before compiling it?

Or for ports of programs like lex/yacc to generate D code?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <ccvs29$1iu2$1@digitaldaemon.com>, Matthew Wilson says...
>
>What do we think of supporting #line?
>
>

Right off the bat, I can say that I use it extensively in DSP, since its basically a preprocessor.   It does a great job of coercing the compiler to generate useful output when a compilation fails, in a way that other languages couldn't possibly hope to achieve.

However, I could really use something like "#line default" or "#line" to signal the compiler to resume the default line number and filename from that point on.

It is something of a wart in the syntax though, and could easily be replaced by
a "pragma()" or some other keyword similar to "version()" and the rest.

Another problem is that is it has zero effect on symbolic information compiled into the code.  When exceptions are thrown, they "appear" to be from the original source file and line number, not from where "#line" specifies in the code.

- Pragma

Matthew Wilson wrote:

>I don't see what's wrong with __FILE__ and __LINE__.
>
>Ruby does this.
>  
>

Whats wrong is that looks ugly.  They should be under some namespace instead. We discussed this before, I mentioned the namespace could be debug but then someone mentioned some similar namespace that was already provided that could be used (I forget the name).

>
>"Kris" <someidiot@earthlink.dot.dot.dot.net> wrote in message
>news:cd0a9m$2drd$1@digitaldaemon.com...
>  
>
>>That's cool, but how about being able to print the current line number and
>>source file using #line and #file or equivalent? Perhaps treat them as
>>char[], so you can do something like printf ("file %.*s, line %.*s\n",
>>#file, #line) ?
>>
>>Why would one wish to do that, you ask? Well, it's really very useful for
>>    
>>
>a
>  
>
>>remote-logger to indicate which file a log-event was generated from, and
>>even more so when it tells you the source line number. Currently there's
>>    
>>
>no
>  
>
>>reasonable way for mango.log to produce that kind of information as it
>>    
>>
>spits
>  
>
>>out log events to the Chainsaw console ...
>>
>>
>>
>>"Walter" <newshound@digitalmars.com> wrote in message
>>news:cd02p5$1vj6$1@digitaldaemon.com...
>>    
>>
>>>"Andy Friesen" <andy@ikagames.com> wrote in message
>>>news:ccvvum$1pi6$1@digitaldaemon.com...
>>>      
>>>
>>>>Matthew Wilson wrote:
>>>>
>>>>        
>>>>
>>>>>What do we think of supporting #line?
>>>>>          
>>>>>
>>>>The only use for it I can think of is for tricking the compiler into
>>>>outputting 'correct' line numbers and filenames in error messages when
>>>>compiling code that is the output of some preprocessor.
>>>>
>>>>If D even needs it, shouldn't it be a pragma?
>>>>        
>>>>
>>>The #line is there in D so that D can handle the output of the C
>>>preprocessor.
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:cd04js$22sn$1@digitaldaemon.com...
> This is not what I mean. I meant in the same way that C/C++ compilers use it, i.e. #line N stipulates that the next line of course _is_ line N, and error messages respect that.
>
> Thus, we could generate D source from some meta-D, and use a pre-processor to generate the D using #line to keep generated code in accord with the meta-D source.

It already supports that.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:cd0knm$2v4r$1@digitaldaemon.com...
> Walter wrote:
> > "Andy Friesen" <andy@ikagames.com> wrote in message news:ccvvum$1pi6$1@digitaldaemon.com...
> <snip>
> >> If D even needs it, shouldn't it be a pragma?
> >
> > The #line is there in D so that D can handle the output of the C preprocessor.
>
> For people who've found an inadequacy in D's replacement features, and so decide to run their code through the preprocessor before compiling it?
>
> Or for ports of programs like lex/yacc to generate D code?

It's handy for any potential programs that use D as an intermediate code, yet wish to have error messages refer to whatever the original source text was.