sailormoontw wrote:
> My problem, maybe not related to this topic, is that the D programs written in
> maybe 2002 2003 2004 is not compatible with the current D compiler, and the
> library is not compatible too. I got a error using the optlink.
> 
> Those authors I don't know why but they might lose interest of D, they just
> don't release newer version of their D program, and the old programs cannot be
> used and I need to re-write them if I want to use.

There have been some code-breaking changes in D, however, every one of them needs only trivial source code changes to update them. Secondly, all versions of the D compiler are available for download, so one can still get the version of dmd that the code was designed for. And lastly, with any programming language, it makes unavoidable sense to archive the compiler and relevant build tools along with the source code to any critical project.

After all, in the process of standardization, even C broke existing code. (Remember the reiser preprocessor? sign preserving integral promotions?)

Sean Kelly wrote:
> Chad J wrote:
>> Walter Bright wrote:
>>> D can link against C code right now, it just will not compile C code.
>> Sorry I didn't mean link.  Oh and I said C plus plus a lot, but I think the ng cut out the plus plus.  Basically I just want to be able to import .h  files and have it just work.
> 
> Please be specific.  There's a huge differencec between C and C insofar as D support is concerned.

"between C and C plus plus"

> For what it's worth, you only need to translate the things you need direct access to from D.  And in my experience, this is substantially less than what's typically in the header file.  I very much recommend working from the spec as an indicator of what should be available rather than simply opening the header file and going for it.  Assuming a decent spec exists, conversion should go pretty fast.  If no such spec exists, simply follow the dependencies of any functions you wish to call and do the conversion on an as-needed basis.  Maintaining such headers should typically be fairly simple as declarations rarely change across versions.  Simply diff between the old and new set of headers and see if any changes are necessary.  Often there aren't.
> 
>> 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.
> 
> *cough*  Are you truly suggesting that it would be trivial to have the D compiler also compile C code?

I meant C plus plus

Walter Bright wrote:
> 
> There have been some code-breaking changes in D, however, every one of them needs only trivial source code changes to update them. Secondly, all versions of the D compiler are available for download, so one can still get the version of dmd that the code was designed for. And lastly, with any programming language, it makes unavoidable sense to archive the compiler and relevant build tools along with the source code to any critical project.
> 
> After all, in the process of standardization, even C broke existing code. (Remember the reiser preprocessor? sign preserving integral promotions?)

Not to mention the fact that D is still in beta--changes are to be expected at this point.


Sean

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.

Don't make it part of the spec, but make it part of the toolset.  At least while C plus plus is still popular.

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

And listen to the uproar when it then is to be removed!

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Ben Cooley wrote:
> I would suggest that a standard C and C plus plus compiler and parser be
> integrated into D, and that it not "convert" files, but just parse them directly
> without modification.  If the equivalent C or C plus plus construct is not
> available in D, D should provide a way of accessing that construct as a foreign
> object.  

That is a good idea, and I've toyed with it. The problem with it is that it pulls the rug out from other implementations of D. People won't want to use them because they'll expect the dmd 'extension' of being able to parse .h files directly.

Sean Kelly wrote:
> Walter Bright wrote:
>>
>> There have been some code-breaking changes in D, however, every one of them needs only trivial source code changes to update them. Secondly, all versions of the D compiler are available for download, so one can still get the version of dmd that the code was designed for. And lastly, with any programming language, it makes unavoidable sense to archive the compiler and relevant build tools along with the source code to any critical project.
>>
>> After all, in the process of standardization, even C broke existing code. (Remember the reiser preprocessor? sign preserving integral promotions?)
> 
> Not to mention the fact that D is still in beta--changes are to be expected at this point.

I couldn't agree more (with Walter and Sean). I keep hearing how D changes so fast that it's impossible to keep track with its current state and specification - but I keep hearing that from people who haven't *really* taken a look at D and its evolution. I've been maintaining a codebase of around 30K LoC since around DMD.086 and the modifications required to make it compile with DMD.157 have been marginal.
As far as I am concerned, even changes that might require more work are welcome because each one of them makes the language better.

Keep up the great work, Walter !


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Sean Kelly wrote:
> Sean Kelly wrote:
> 
>>Chad J wrote:
>>
>>>
>>>Sorry I didn't mean link.  Oh and I said C plus plus a lot, but I think the ng cut out the plus plus.  Basically I just want to be able to import .h  files and have it just work.
>>
>>Please be specific.  There's a huge differencec between C and C insofar as D support is concerned.
> 
> 
> "between C and C plus plus"
> 

Gotcha :)

> 
>>For what it's worth, you only need to translate the things you need direct access to from D.  And in my experience, this is substantially less than what's typically in the header file.  I very much recommend working from the spec as an indicator of what should be available rather than simply opening the header file and going for it.  Assuming a decent spec exists, conversion should go pretty fast.  If no such spec exists, simply follow the dependencies of any functions you wish to call and do the conversion on an as-needed basis.  Maintaining such headers should typically be fairly simple as declarations rarely change across versions.  Simply diff between the old and new set of headers and see if any changes are necessary.  Often there aren't.
>>

OK, seems like good advice.

>>
>>>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.
>>
>>*cough*  Are you truly suggesting that it would be trivial to have the D compiler also compile C plus plus code?

No.  I wouldn't know.

If the objection to this sort of thing is technical, then I'm fine. What bugs me is that the objection seems to be based on some kind of fear that DMD's support of C plus plus would imply that other compilers must support it.  I disagree.

It's like saying that if I were to make an external tool to translate C plus plus headers to D, that it would automagically become part of the language spec and everyone would have to use it forever.

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.

> Don't make it part of the spec, but make it part of the toolset.  At least while C plus plus is still popular.

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?).

> 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.