A gentle critque..

[Dave]

In article <e4aoo6$2st8$2 at digitaldaemon.com>, Dave says...
>
>Dave wrote:
>> 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.
>>>
>>
>
>All those "C"'s should read "C plus plus" (what the heck is stripping
>the "plus plus"'s for this NG?).
>

BTW - This doesn't seem to have anything to do with the NG server, but
SeaMonkey's incarnation of Thunderbird is apparently 'hiding' the '++' in C++ (I
noticed other posts with the same problem so assumed it was something to do with
the NG server)...

>> 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.
>> 
>>> Don't make it part of the spec, but make it part of the toolset.  At
>>> least while C plus plus is still popular.