A gentle critque..

[Ben Cooley]

In article <e4aohg$2st8$1 at digitaldaemon.com>, Dave says...
>
>Chad J wrote:
>> Walter Bright wrote:
>>> Chad J wrote:
>>>
>>>> I have even more trouble believing that current D compilers shouldn't
>>>> support C plus plus integration just because it might make C plus plus
>>>> compilation a required capability of a D compiler.
>>>
>>> Take a look inside one of the STL header files - how can one access it
>>> without being a C compiler?
>> 
>> Agreed.  You need C plus plus compilation ability to use C plus plus
>> headers as they are.
>> 
>> What I'm talking about though is this notion that DMD supporting C plus
>> plus compilation somehow implies that every D compiler created from then
>> on will also support C plus plus compilation.  I don't agree with that.
>>  I think it reeks of fallacy.
>> 
>> I'd say that C plus plus support for the first couple D compilers would
>> make D more likely to become mainstream or become mainstream faster.
>> The objective is no different than that of an external tool that
>> translates C headers into D headers, but it may be easier to do since it
>> puts a fully functional C plus plus parser at your disposal (at least I
>> think it does).  Just make sure to clearly mark the C plus plus
>> capabilities as something DMD specific, a bundled tool really, and
>> everything should be dandy.  Same goes for GDC if it were to add such a
>> faculty.
>>
>
>There seems to be an assumption that converting C++ to D is a
>straight-forward thing to do, even if you have a C++ front-end at your
>disposal. Heck, IIRC CFront was eventualy abandoned in part because C++
>became complicated enough that a C++ to C converter was barely feasible
>any longer (beside the obvious other advantages of native C++ compilers).
>
>My point is that really what your suggesting is another whole compiler
>here...
>
>And if you don't have a compiler handy, there are quite a few open
>source and commercial "compiler-compilers" out there, but I've never
>heard of a commercial compiler that has been developed with one of them.
>And, I've rarely heard of any other tools like syntax high-lighters,
>class browsers and such that are developed that way, either. There has
>been quit a few D parser projects started using tools like Antlr, and
>they seem to get 90% there, but then I suspect the developer runs into
>cases where those tools aren't quite flexible enough and/or create very
>bloated and slow compilers.
>
>All this leads me to conclude that what you're asking for would require
>another hand-made compiler to do properly, and for dubious gain since
>the code created would just be C++ disguised as D and wouldn't take
>advantage of a host of D's other features.

There are several full parsers out there available today.  The GCC frontend for
C++ is one.. it's used in GCC-XML.   Another would be the elsa parser, which
seems to do a fairly good job on our massive codebase, though we do have to
macro define several linux and microsoft specific additions.

Parsing is not the most difficult aspect, it's actually providing in-language
facilities in D to utilize the constructs in Cpp.  For this facility, you would
generally need to integrate a Cpp compiler into the D compiler.  Sure this would
be an ugly hack, but such is life.  The advantage would be that the D compiler
could call the Cpp compiler to instantiate cpp code it needed to integrate Cpp
constructs.

The syntax in D for accessing Cpp classes, macros, and templates need not be
particularly elegant, just not needlessly difficult.  You wouldn't need to have
D pretend that a C++ class was a D class, or have D conform to C++ syntax...
merely make it possible to instantiate classes, templates, use macros, and do
what you need to do with an external library without having to re-code it or
spend weeks creating wrappers.

If you would like to see how such a convergence would work, take a look at
"managed C++".  With .NET, microsoft faced the same problem.  How do you get
people to migrate to .NET when they have large quantities of code written in C
and C++?  Microsofts answer was the "IJW" philosophy.  You can take any C/C++
code and simply compile it in .NET, then add .NET specific constructs to make
the C++ code play nice in the .NET world.  You do not need to recode your
existing C++ libraries in C#.  This is not really an apples to apples
comparison, because Microsoft didn't extend C# to parse C or Cpp headers (which
it should have in my opinion), but it did make Cpp play nice with .NET and that
was very important for the adoption of .NET.