A gentle critque..

Bill Baxter Bill_member at pathlink.com
Tue May 16 02:05:58 PDT 2006


In article <e4brql$1ihs$1 at digitaldaemon.com>, BCS says...
>
>In article <e4baj5$aut$1 at digitaldaemon.com>, Walter Bright says...
>>
>>BCS wrote:
>>> What do ya think new D users would think about a converter that does 
>>> 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? 
>>> Say just global function prototypes, structs typdefs (c style) and 
>>> anything else that would be easy to get right. Some of the stuff (in C, 
>>> the most common stuff) translates directly, and shouldn't be that bad to 
>>> translate.
>>
>>There is always something in each header that is not translatable :-(
>
>But with any luck you wont need that part most of the time. What I'm suggesting
>is a tool that does a best effort translation generating a header for parts that
>can always be done (file scope function, simple structs, global variables of
>common types, etc.) in other words, the bulk of most C headers.

Note that that's already how SWIG works pretty much.  It doesn't have a full C++
parser, but it can parse and generate wrappers for a lot of simple C++ code just
by including the header.  It's not going to work for wrapping wxWidgets or
something like that, but it is useful to have.

There has also been talk in the SWIG mailing lists about generating C wrappers
from C++ code.  Don't think anyone is actively working on it, but there is
interest in such a thing out there.  That could be useful for D purposes too.
With a little work it could lead to the ability to use any SWIG-wrapped C or C++
code from D.  It's a thought for an alternative to trying to write a C++ to D
translator type thing.

Finally about whether it's worth it to be able to call C++ code, I'd like to
point to the example of Fortran.  It was superceded by better languages with
better syntax many many years ago, but people still use it.  I hear a lot of
people saying "we're better off without all that old junky C++ code anyway".
But the fact of the matter is that nobody in the real world has the time or
budget to go back and rewrite all their old code (that already works and has
been debugged) just because it would be easier to read in a new language.  Most
numerical work is still based on lots of legacy fortran code, even if the front
end code is now written in C or C++ or Python or what have you.   It just makes
no sense to rewrite gobs and gobs of stuff that works.

Gotta go so there's no time to finish my point, but there are some interesting
parallels in this debate with the migration away from Fortran, I think.  

Bill Baxter



More information about the Digitalmars-d mailing list