"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:adgceo$202v$1@digitaldaemon.com...

> The problem is that there is no complex type defined by the standard to my knowledge. Standard C++ defines it as template. Regarding GCC, I just

Then use std::complex:

    typedef std::complex<double> complex;

Or that built-in __complex__ type.

> > > - Use of strtof() and strtold(). Neither my Windows compiler or GCC
have
> > The solution is obvious: write your own versions of these. =)
>
> Yes its obvious. But it still represents a challenge.

Life would be dull without challenges, no? =)
Besides, it's not a real challenge, after all... by the way, you might want
to take a look at atof() in my math2 module. It works with extended and
understands D features like hex floats. I guess one could easily make
strtof() and strtold() out of it.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adhg57$49n$1@digitaldaemon.com...

> > I don't see why someone couldn't write:
> >
> > -0xfeed.beef // same as -65261.7458343505859375

You can.

> > 0b10.01  // same as 2.25

You can't =(

> > although since e is a valid hex char it would require a different form
of
> > scientific notation.

In hex notation, you use p: 0x8p2 == 8 * 16^2

In article <adg4t2$1obg$2@digitaldaemon.com>, Walter says...
>
>Could GCC simply be compiled with the g++ compiler, rather than gcc? That would then make it easy to interface D's C++ front end to GCC's C.

I don't think so.  GCC is not even ISO C.  It is intentionally written to
be compiled by Kernighan and Ritchie C (KRC).  The purpose is to
make the GCC compilable by as many systems as possible, and darn
near everything has a KRC compiler somewhere, for free.


Andy Walker

In article <3CFBB141.7080909@apache.org>, andy says...
>
<snip>
>
>Here are disadvantages:
>
>1. We'd never get into the GCC standard distribution that way.  I'm not sure if we want that, but wider adoption for D would certainly result from default inclusion.

This is the only reason I really want to develop a Bright D frontend for GCC in the first place.

>
>2. We'd forever be *out of sync* with the GCC folks.

That would not bother me, one way or the other.  I am not part of their religion.  I have my own.

>
>3. The GCC folks would think us odd and probably not work very closely with us.

I sort of take that as a given.

>
>4. Supporting a divergent version of GCC might be a massive undertaking

Yes.

>
>5. I bet this would be a lot of work.

I believe this qualifies as a very literal understatement.

>
>6. There are no C++ examples of GCC Front ends (or existing front ends written in C++ that I know of).  We'd be on our own.

Very much so.

>
>Advantages:
>
>1. Resist the effort of rewriting the D Front end in C

The economic comparison is between rewriting DMD to C, versus rewriting the GNU backend into C++.  I prefer the former.  I am not sure the latter is even possible.  There is a reason why the serial port handler for Windows is still written for a 16 bit machine: it still works.

>2. The D community is largely composed of C++ advocates who might be more likely to contribute with a C++ effort.

There is an old saying in the American South.  "We never brings a cake.  I bring a cake."  Help would be wonderful, but it is unrealistic to count on it.

>
>Anything I missed?
>
>-Andy
>
<snip>

Andy Walker

Thank you for all the fixes, Walter.

In article <adgbub$1vgu$1@digitaldaemon.com>, Walter says...
>
>
>"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:adg4i1$1o2s$1@digitaldaemon.com...
>> I agree. The problem is that the code will depend on the C++ RTL which GCC probably does not link with. A solution to this is to put the C++ code
>into
>> a shared library and include the C++ RTL in the shared library and resolve references to that internally. There might be problems initializing the
>C++
>> RTL, but that can be overcome. I have used this technique a couple of
>times.
>> Its not without problems, though.
>
>What's the issue with recompiling gcc with g++?
>
>> I would prefer a pure C solution, and in any case, we need a solution that
>> does not use features specific to DMC. I have found:
>> - complex_t
>> - Hexadecimal notation of double literals supported by strtod()
>> - Use of strtof() and strtold(). Neither my Windows compiler or GCC have
>> them,
>>   and they are not part of x/Open specification either. If strtod() is
>used
>> in stead
>>   of strtold() precision is lost. I don't know it this can be solved.
>
>These are all part of the standard C99 spec. I'm a little surprised they are not in gcc. Doesn't gcc support long doubles, if so, isn't there a conversion in the gcc library for it? If not, just use strtod(), that's what I used for bootstrapping myself. One can always go back later and upgrade it.
>
>
>> - Use of contracts.
>
>Those can just be #ifdef'd out.
>
>> I have a working lexer, and a partial bison grammar that has all
>statements
>> and expressions. I've stopped, temporarily anyway, for a number of
>reasons:
>> - The D specification is incomplete in the sense that it covers all
>language
>> constructs. For examle, BasicType and BasicType2 are not described.
>
>What those do is enable both C and D style array declarations to work:
>    int foo[];
>    int[] foo;
>both declare foo to be an array of int's.
>
>> I prefer a bison solution over recursive descent because it allows grammar documentation to be extracted directly from the source. My approach is
>also
>> a little different from Walter's regarding strings. I use wchar_t's everywhere internally.
>
>That will work, but since wchar_t's on linux are 4 bytes, I found with another project on linux that it consumed lots of memory and ran slower. I also ran into maddening gaps in gcc's library support for wchar_t's.
>
>> Some problems I have identified are described below. Don't take me wrong.
>I
>> think that Walter has been doing a great job, and I hope a list with even the smallet things described will help making it a better product.
>
>It's great that you're posting these problems, that enables me to fix them.
>
>> In http://www.digitalmars.com/d/lex.html :
>> - "synchronized" not listed as keyword
>
>Yes it is!
>
>> - "===" and "!==" are not described as tokens.
>
>Fixed.
>
>> - "asm", "delegate" are is not described as a keywords.
>
>Fixed.
>
>> - "volatile" is described as a keyword. However, it is stated in
>>   "statement.html" that "D has no volatile storage type". I suspect
>>   that way to many keywords are reserved.
>
>volatile is now removed.
>
>> - Literal grammar uses 0b, not 0x, for hexadecimal literals.
>>   So this is wrong:
>>             Hexadecimal:
>>               0b HexDigits
>
>Fixed.
>
>> - It is not specified that 0B and 0X are valid prefixes for literal
>> integers;
>>   Only 0b and 0X are described. Case does not matter in "lexer.c".
>
>Fixed.
>
>> - It is stated:
>>         "Floats can be in decimal or hexadecimal notation, as in standard
>> C".
>>    Hexadecimal notation is not standard, is it? Is definitely is not
>> standard
>>    C++ (not described in ISO/IEC 14882). It expect this will cause
>>    some difficulty because the underlying C library does not support
>>    hexadecimal notation using strtod().
>
>It is in C99, but not in C++98.
>
>> http://www.digitalmars.com/d/expression.html
>>
>>     ShiftExpression:
>>       AddExpression
>>       AddExpression << AddExpression
>>       AddExpression >> AddExpression
>>       AddExpression <<< AddExpression
>>     The <<< operator is not defined by "lex.html", and "dmd" will not
>> compile it.
>>     It is probably a typo, and the operator should be >>>. The same
>problem
>>     exists with <<<= vs. >>>=.
>
>Fixed.
>
>>     In the definition of the ShiftExpression above, AddExpression should
>be
>>     replaced with ShiftExpression on the left side of the operator (in a
>> Bison
>>     grammar)The same goes for other binary expression. If not, expressions
>>     like a+b+c will not compile.
>
>a+b+c should parse as ((a+b)+c). As long as that works, you should be ok.
>
>>     "ArgumentList" is not described.
>>     "NewExpression" is not described.
>
>I'll add these.
>
>>     The description of variable initialization is ambiguous. It says:
>>         IdentifierList:
>>           Variable
>>           Variable , IdentifierList
>>         Variable:
>>           Identifier
>>           Identifier = Expression
>>     "Expression" is a comma separated list of AssignmentExpression's, and
>it
>>     therefore conflicts with IdentifierList. So, Expression should be
>>     AssignmentExpression instead (like it is in C).
>
>Done.
>
>> http://www.digitalmars.com/d/statement.html
>>
>>     {} is both an EmptyStatement and a BlockStatement. EmptyStatement
>>     should not be in the grammar.
>
>Fixed.
>
>>     Synchronize Statement uses the keyword "synchronize". However, the
>>     keyword is defined as "synchronized" (with a "d") in both "lexer.c"
>and
>> "lex.html".
>
>Fixed.
>
>>     How about rethrowing exceptions? The ThrowStatement does not
>>     allow throw to be used without an expression:
>>         ThrowStatement:
>>           throw Expression ;
>
>This has been discussed at length. It's probably a good idea.
>
>>     The AsmStatement is described as:
>>         AsmStatement:
>>       { }
>>       { AsmInstructionList }
>>     It lacks the "asm" keyword.
>
>Fixed.
>
>> In http://www.digitalmars.com/d/declaration.html :
>>
>> - BasicType and BasicType2 are not described.
>
>Yes, this needs work.
>
>> - Only const, static, final, synchronized, and deprecated are described
>>    as storage specifiers (or whatever it should be called). However,
>>    "parser.c" recognizes many more.
>
>This needs work too.
>
>

Andy Walker

In article <adgch0$203k$1@digitaldaemon.com>, Walter says...
>
>
>"andy" <acoliver@apache.org> wrote in message news:3CFBB141.7080909@apache.org...
>> Walter wrote:
>> > Could GCC simply be compiled with the g++ compiler, rather than gcc?
>That
>> > would then make it easy to interface D's C++ front end to GCC's C.
>> Cost / benefit analysis --
>> Here are disadvantages:
>> 1. We'd never get into the GCC standard distribution that way.  I'm not
>> sure if we want that, but wider adoption for D would certainly result
>> from default inclusion.
>
>The fact that apparantly nobody has already done this with GCC is discouraging.

This is a direct result of the GCC philosophy: simple portability to darn near
everything.  There seems to be a KRC compiler everywhere, for free.  For
C++, they are all different from each other, often even different from other
versions from the same vendor.  That makes maintaining a generic compiler
a nightmare.

>
>> 2. We'd forever be *out of sync* with the GCC folks.
>
>That's a serious problem.
>
>> 3. The GCC folks would think us odd and probably not work very closely with us.
>
>They probably will anyway <g>.
>
>> Advantages:
>>
>> 1. Resist the effort of rewriting the D Front end in C
>> 2. The D community is largely composed of C++ advocates who might be
>> more likely to contribute with a C++ effort.
>
>Is g++ written in C, too?

Yes.  Not only yes, but yes: KRC.

Andy Walker

"Andy Walker" <Andy_member@pathlink.com> wrote in message news:ae1hij$1pmn$1@digitaldaemon.com...
> There is an old saying in the American South.  "We never brings a cake.  I bring a cake."  Help would be wonderful, but it is unrealistic to count on
it.

<g>

Andy Walker wrote:
> In article <3CFBB141.7080909@apache.org>, andy says...
> 
> <snip>
> 
>>Here are disadvantages:
>>
>>1. We'd never get into the GCC standard distribution that way.  I'm not sure if we want that, but wider adoption for D would certainly result 
> 
>>from default inclusion.
> 
> This is the only reason I really want to develop a Bright D frontend for GCC in the first place.
> 

exactly.

> 
>>2. We'd forever be *out of sync* with the GCC folks.
> 
> 
> That would not bother me, one way or the other.  I am not part of their religion.  I have my own.
> 

Right, the issue being that being in step makes inclusion easier and maintenance nicer and a higher chance of cooperation.

> 
>>3. The GCC folks would think us odd and probably not work very closely with us.
> 
> 
> I sort of take that as a given.
> 

I'm not quite as sure.


>>5. I bet this would be a lot of work.
> 
> 
> I believe this qualifies as a very literal understatement.
> 

definitely.

>>
>>1. Resist the effort of rewriting the D Front end in C
> 
> 
> The economic comparison is between rewriting DMD to C, versus rewriting the GNU backend into C++.  I prefer the former.  I am not sure the latter is even possible.  There is a reason why the serial port handler for Windows is still written for a 16 bit machine: it still works.
> 

agreed.

> 
>>2. The D community is largely composed of C++ advocates who might be more likely to contribute with a C++ effort.
> 
> 
> There is an old saying in the American South.  "We never brings a cake.  I bring a cake."  Help would be wonderful, but it is unrealistic to count on it.
> 

Yes...  (I hail from Carolina).  But I envision this a bit more like a pot luck or pig pickin'

-Andy

> 
>>Anything I missed?
>>
>>-Andy
>>
> 
> <snip>
> 
> Andy Walker

Walter escribió:
> 
> While D supports unicode source files, unicode comments, unicode strings,
> and generating unicode apps, the identifiers are standard C identifiers.
> This ensures compatibility with existing linkers, librarians, debuggers,
> disassemblers, etc. Rewriting all of that stuff is way, way beyond the scope
> of D!
> 
> 

Is there a way to change that?

---------------------------
Carlos Santander B.

| Walter escribió:
| >
| > While D supports unicode source files, unicode comments, unicode
strings,
| > and generating unicode apps, the identifiers are standard C identifiers.
| > This ensures compatibility with existing linkers, librarians, debuggers,
| > disassemblers, etc. Rewriting all of that stuff is way, way beyond the
scope
| > of D!

(written on 2002-06-03 14:44, by the way. that'd be june 3th, 2002)

-------------------------
Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01