A gentle critque..

Ben Cooley Ben_member at pathlink.com
Tue May 16 09:24:17 PDT 2006


In article <e4cgup$2te2$1 at digitaldaemon.com>, Bill Baxter says...
>
>In article <e4ca0r$2hvj$1 at digitaldaemon.com>, Paulo Herrera says...
>>
>>Bill Baxter wrote:
>>> 
>>> 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
>>Hi everybody,
>>This is my first post to this mailing list.
>
>Howdy.
>
>>
>>About the Fortran example
>>-------------------------
>>I think the Fortran example is a bad one. Which better languages were 
>>available long time ago? C or C++? Do you think C or C++ have a clean 
>>syntax? I don't think so, that's why I've been exploring D.
>>There are a lot of C (e.g. GSL, PETSc) and C++ (e.g. ITL, Blitz++) 
>>numerical libraries, so I don't think that is the main reason people 
>>still use Fortran.
>
>
>My point was that while some people still use Fortran (and others have moved
>on), LOTS of people still use old Fortran *libraries*.  I.e. C/C++ are to
>Fortran as D is to C/C++.  And just as with Fortran, there's just no value
>proposition in rewriting gobs of well-known, well-tested, well-debugged code,
>like that available at netlib.org.  Dreaming that everything of value that has
>ever been written in other languages (including Fortran, C, and C++) will get
>rewritten in D is just that, dreaming.  Heck, from what I hear there are still
>plenty of mainframes out there, cranking away on Cobol code.  Because it just
>doesn't make sense to spend a lot of resources fixing what ain't broke.
>
>Writing new libs from scratch is certainly the best in the long run.  But that
>takes time, and it takes a lot of raw man hours.  In the short term, it seems
>obvous to me that the best bet is to increase the number man-hours by increasing
>the number of 'mans' -- attracting as many folks as possible to D.  But starting
>off by saying "sorry you can't use your old code" is just going to put people
>like Ben off from the start, thereby shrinking the pool of potential
>contributors.   I don't think D needs compatibility with C++ -- I'm inclined to
>think it's pretty hopeless even with a working C++ compiler as a starting point
>-- but some tools to create wrappers for existing C++ code (a la SWIG), should
>be doable, and would be a huge help in luring people to D.  
>
>I would venture to guess that the vast majority of C++ code that people write in
>real life is not at all like the STL, but more like the subset of C++ that's
>contained in  Java.  Those are the things you want to target (most bang for the
>buck), and, no co-incidence, those are precisely the things that SWIG targets.
>Libraries like Blitz++ and ITL that go crazy with C++ templates are so steeped
>in C++-specific issues that I doubt they could be wrapped reasonably anyway,
>whether done by hand or by a wrapper-generator.
>
>Apparently this idea to use SWIG has been discussed (and even worked on?) a bit
>before:

I agree. And I'm not interested anymore in arguing about "why" this should be
done.  If it isn't made obvious to anyone by the post about "finally having the
Windows API translated to D".. then it never will be.  <rolls eyes>

I think the practical way to do this is to allow D to comprehend basic C++
vtable types, access C++ members and methods and be able to instantiate macro
constants.  Other C++ interop would be handled using inline cpp { } blocks which
could access D vars.  

The compiler would offload instantiating templates, cpp {} asm blocks, and
inlines into a secondary compiler generated D/cpp interop file, and only need to
worry about either calling simple vtable functions and accessors directly, and
defer any more complicated interop to go through such as complex inlines or
templates through generated C function wrappers in the cpp file.

I'm not sure the GCC-XML format is the best data source for the header database.
And even if it is, the headers would have to be preprocessed to pick up macros
in any case.  But it should work to start out with.

In any case, I think this would be sufficient:

// Includes the given header
include "header.h" define(MACRO) define(MACRO=value) define(MACRO="VALUE")

// Indicates a cpp code block.  Translates to a call to a c function with the
parameters .
cpp {
stdout << "Hello from C++\n";
}

// For simple template instantiation.  Creates a wrapper type in the cpp file
for this type.
cpptype VectorInt { std::vector<int> } MyVectorInt;

// For instantiating constants
cppconst int NULL { NULL };

// Creating a cpp class
MyClass c = new MyClass("A class\0");

// Calling a method on a cpp class
c.Method("String Argument\0");

// Handling an exception
cpp {
try {
c->ThrowException(%%str);
}
catch (std::string ex)
{
%%ret = ex;
}
}







More information about the Digitalmars-d mailing list