Russ Lewis wrote in message <3B7D817E.B453B499@deming-os.org>...
>Walter wrote:
>> So, while I claim no credit for the design of C++, I do claim some role
in
>> the early establishment of C++ as a major language rather than a
curiosity.
>> It's also the basis for my figuring that a native implementation is
needed.
>Fair enough.  Can you, then, give a guesstimate how much more/less work it
is
>to make a compiler as compared to a translator?  Would a translator get out
the
>door faster, and be a good demonstration/standard setting mechanism, or
would
>it take nearly as long as a full compiler?

Given an existing back end, it is easier to connect to that than generate C. Making a full optimizer/code generator is *far* more work than generating C.

One nice fallout with D is that since it is so easy to lex, parse, etc., it is going to be a smokin' fast compiler. <g>

>Frankly, after reading that somebody with real compiler experience is
actually
>looking into D, I'm itching to use this language *soon*.  :)  It would make some of my projects SO much easier!


Well, I'm itching to use it too! It's (of course) the language I always wanted, but nobody else made. In my experiments with it, it helps me get my own work done much faster.

"Walter" <walter@digitalmars.com> wrote in message news:9lk2ce$2bo3$1@digitaldaemon.com...
> Given an existing back end, it is easier to connect to that than generate
C.
> Making a full optimizer/code generator is *far* more work than generating
C.
>
> One nice fallout with D is that since it is so easy to lex, parse, etc.,
it
> is going to be a smokin' fast compiler. <g>

Would the front end be initially written in D? Always hard to boot strap, but it would speed up things concerning implementation issues. --Kent

Walter wrote:
> 
> Dave Nebinger wrote in message <9lji2j$1n07$1@digitaldaemon.com>...
> >Would translating into C and/or C++ have a positive or negative effect on language acceptance?  If anything, I'd guess negative (increased build
> times
> >to translate from one language to another).
> 
> I implemented the first native C++ compiler. Before then, C++ was a translator put out by AT&T.

Minor nit:

Not that it hurts any of the other points you make here (in fact, it supports your points about performance), but IIRC, Stroustrup goes to some lengths in _Design and Evolution..._ to explain that Cfront wasn't a 'mere translator'[1], but a full-blown compiler that used C as the target language instead of assembly or machine language. Zortech would thus be 'the first C++ compiler to target machine-native object code', or something awkward like that. :)

-Russell B

[1] All compilers are 'translators', but Cfront doesn't merely rewrite C++ into C. In particular, all compile-time errors are supposed to be caught be Cfront, rather than the backend.

Kent Sandvik wrote in message <9lk3ga$2chc$1@digitaldaemon.com>...
>
>"Walter" <walter@digitalmars.com> wrote in message news:9lk2ce$2bo3$1@digitaldaemon.com...
>> Given an existing back end, it is easier to connect to that than generate
>C.
>> Making a full optimizer/code generator is *far* more work than generating
>C.
>>
>> One nice fallout with D is that since it is so easy to lex, parse, etc.,
>it
>> is going to be a smokin' fast compiler. <g>
>
>Would the front end be initially written in D? Always hard to boot strap, but it would speed up things concerning implementation issues. --Kent


Because it's bootstrapped, it's in C++.

Russell Bornschlegel wrote in message <3B7D9302.AF5F8B9F@estarcion.com>...
>Walter wrote:
>> I implemented the first native C++ compiler. Before then, C++ was a translator put out by AT&T.
>Minor nit:
>Not that it hurts any of the other points you make here (in fact,
>it supports your points about performance), but IIRC, Stroustrup
>goes to some lengths in _Design and Evolution..._ to explain that
>Cfront wasn't a 'mere translator'[1], but a full-blown compiler that
>used C as the target language instead of assembly or machine
>language. Zortech would thus be 'the first C++ compiler to target
>machine-native object code', or something awkward like that. :)


Bjarne's legitimate complaint in the 80's was that people dismissed cfront as just a "preprocessor". It was not a preprocessor (in the sense of a text preprocessor), but a compiler. I don't remember anyone at the time dissing it as a "mere" translator.


I agree with Bjarne that successful translators must be real compilers - but they are not *native* compilers. Translators required the addition of a full blown C compiler. Bjarne's strategy of making cfront a translator made C++ quickly available on a wide variety of platforms. AT&T's generous policy of letting others make implementations was crucial. I remember writing a letter to AT&T's lawyers asking them if I could call my product "C++", since AT&T owned the name. (They said yes!) I wish I could find that letter, it would be a nice bit of memorabilia. I don't think anyone else ever asked!