In article <e4c2nn$20c9$1@digitaldaemon.com>, Don Clugston says...
>
>Walter Bright wrote:
>> Don Clugston wrote:
>>> The Windows API project
>>> http://www.prowiki.org/wiki4d/wiki.cgi?WindowsAPI
>>> is well on the way towards converting all of the Windows API headers
>>> (including DirectX) into D. Stewart Gordon has done a great job of
>>> ensuring that this will be the definitive translation in D, and many
>>> of these types of problems will disappear once this project is
>>> complete, because we'll have a standard code base to improve.
>> 
>> I agree. That project is a first rate example of what the D community can do in a collaborative effort. Kudos to all involved with it.
>
>We'll also need updated versions of the Windows import libs (since the ones provided with D don't have the recent functions). Do you have a license to redistribute the more recent ones?

Also, you might be able to use these .def files that I came up with to create
lib files:
http://svn.dsource.org/projects/bindings/trunk/def/


>Secondly, do you think it would be possible to use pragma(lib) to
>eliminate the concept of 'default libraries' at least for the Windows
>headers?
>It seems to me that that's another C/C++ annoyance that D could abolish.

That sounds like a good idea.

jcc7

In article <e4ca0r$2hvj$1@digitaldaemon.com>, Paulo Herrera says...
>
>Bill Baxter wrote:
>> In article <e4brql$1ihs$1@digitaldaemon.com>, BCS says...
>>> In article <e4baj5$aut$1@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
>Hi everybody,
>This is my first post to this mailing list.
>
>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.
>
>I'm a scientist that have to write numerical codes. I've been searching for a better language (combination of languages) than Fortran for some time. I've used Fortran+F2PY+Python, C++, Python+SWIG+C++, and Java to write code. None of those alternatives to replace Fortran were completely satisfactory. One of the reasons is that Fortran is very good at doing number crunching. It's very fast, it includes array operations, and it is easy to learn.
>
>However, Fortran95 (as standard) lacks other tools, such as: conditional compilation, unit testing, true OO programming, command line arguments (that was only fixed in the new 2003 standard), etc. To me those are the most interesting D's features. In fact, I think D features make it a terrific alternative to Fortran. however, there are a couple of things that would make it even better: array operations (it's in Walter's plans) and OpenMP support.
>
>About using different languages
>-------------------------------
>I understand that some times is useful to be able to program using a combination of languages. However, those cases should be the exception if you want to take advantage of a better language features. Mixing languages always adds problems and, in my opinion, makes difficult to have a clear design. As example, you can check how difficult has been creating a good SWIG interface for C++ or the problems of the maintainer of F2PY (Fortran to python interface generator) to support new compilers.
>
>I think D already has a very easy way (probably the easiest with the exception of C++) to communicate with C if needed. Why to spend more valuable time improving that?
>
>About native libraries
>----------------------
>I think the way to go is to create QUALITY native D libraries. I think we usually overestimate the cost of porting/developing native libraries. As example, this weekend I played to create a native XML SAX parser. In a couple of hours I had a useful version. I'm not sure if it was easier/shorter to link to a C library (that was my first idea).
>
>I think D main problem is the lack of good quality (documented) native libraries. More than 80% of project at www.dsource.org are unmaintained and/or don't have documentation. Therefore, collaborating in or using those projects is impossible. In my opinion libraries and good quality documentation are the main reasons of the success of Python and Java.
>
>About writing a native XML library
>----------------------------------
>If someone is interested in creating native SAX and DOM XML libraries please drop me an email. By the way, XML is another effective way to communicate (actually, exchange data) between different languages.

Someone may have already have started such a project. Have you seen this list? http://www.prowiki.org/wiki4d/wiki.cgi?AllLibraries/XmlLibraries

The rest of them may be abandoned, but at least Mango (which is much, much more than just an XML tool) is still in active development.


>I apologize if part of this email is off topic in this thread. Paulo.

Don't worry about it. Threads go off-topic all topic all the time around here. This thread was practically off-topic from the beginning. ;)

jcc7

Bill Baxter wrote:
> Apparently this idea to use SWIG has been discussed (and even worked on?) a bit
> before:
> http://www.digitalmars.com/d/archives/17315.html
> http://www.digitalmars.com/d/archives/17289.html
> 
> Yikes that was 2003.  Wonder what happened...

More recently, the Language Machine has shown some promise converting Java to D, using an intermediate language like SWIG does.  Peri Hankey, author of the LM has plans to work on C++ conversion as you discuss here.

http://www.dsource.org/projects/languagemachine

http://languagemachine.sourceforge.net/j2d.html  (or parent for main project page)

BA

In article <e4cgup$2te2$1@digitaldaemon.com>, Bill Baxter says... ..snip...
>Apparently this idea to use SWIG has been discussed (and even worked on?) a >bit before: http://www.digitalmars.com/d/archives/17315.html http://www.digitalmars.com/d/archives/17289.html
>
>Yikes that was 2003.  Wonder what happened...
>
>Bill Baxter

Some people worked on it but I guess they lost interest. (See also http://www.prowiki.org/wiki4d/wiki.cgi?DwithSwig)

I think the problem was that SWIG was too hard to use. It could work, but too much effort was required that it wasn't really worth it. The payoff wasn't enough compared to the initial investment. But I didn't spend much time with SWIG (and I never really knew what I was doing), so there may be other reasons why SWIG never really got used.

Also, there was dsource project started, but I think it was abandoned almost as
soon as it started:
http://www.dsource.org/projects/swig4d
http://www.dsource.org/forums/viewforum.php?f=29

jcc7

Hi, guys.

I've read all this thread during the last days and would like to say something about:

1. I'm already a begginer on D, but I'm impressed with a lot of funcionalities of the language. I'm trying to make some real projects using D and I've fall in love with the language.

2. I think that the "open" architeture of D allows me to develop any library I need. Could be useful if I can get C++ code used directly from D, but I wouldn't like to use a "Frankenstein" thing to make the work.

3. There are a LOT of libraries developed in Java, e.g., parsers generators, XML libraries, report libraries, etc, etc, etc... It seems to me that a conversion from pure Java code to D is not a traumatic experience. So...

4. I'm not so purist about the language. All I want is a language that I can use to make the things work and I can extend it creating all the libs I need. I think that's perfectly possible the use of D in order to achieve this.

5. Looking at the present situation of D, I really would like to see a 1.00 release. When the language left behind the "beta" status, it would facilitate to convince people that the language really has a future and it's not just a dream of someone.

Sorry my (very) bad english.

Cheers from Brasil.

Nilo

In article <e48h8g$pk$1@digitaldaemon.com>, Ben Cooley says...
>
>There are a few major problems with D that still prevent it from being practical for use in the real world.
>
>I'll just list them and note their importance.  Anything witha
>
>- Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
>--------------------------------------------
>
>C++ can do this, D can not.
>
>The size, scale, and prevalence of C and C++ libraries and code make writing wrappers for all of these libraries impractical.  That D can not just easily include C and C++ headers "as is" gives it a serious and I would suggest fatal disadvantage vs. C++.
>
>C++ out of the box could include C header files, meaning that even today I have access to the largest possible body of third party libraries and code.  Binary compatibility with C only is just not good enough.
>
>Incompatibility with C++ ABI...              Importance:    SHOW-STOPPER
>--------------------------------------------
>
>Even if you could include C++ headers, you could not interface with C++ classes. C has abi compatibility with C++, and C++ has ABI compatibility with C.  C and C++ have more or less abi compatibility with most other systems (including COM, CORBA).  D intends to be used for system programming, but is icompatible with the most prevalent existing ABI.
>
>Inability to make D code work with C/C++    Importance:    SHOW-STOPPER
>---------------------------------------------
>
>Likewise, if you write D code, your code exists only in the very small world of D, and will not be useful to the world outside of the D programming community. This makes any library or system you might create only marginally useful, and is a strong disincentive for anybody to actually write code in D for general public consumption.
>
>No support for meta-programming or Macros   Importance:    SHOW-STOPPER
>---------------------------------------------
>
>Say what you will about the unclean use of macros in C and C++, they are critical for a large set of important functionality that C and C++ programmers take for granted.  There are many ways to provide hygenic macro replacesments, true meta programming, or generative programming.  D offers none of these, and no way to replace the functionality lost using macros.
>
>Correct me if I am wrong on this point, but the meta-programming offered by macro code injection is just not easily replaced by mixins, templates or other language features.
>
>Provides no additional support for safe programming vs. C/C++  Importance: HIGH
>---------------------------------------------
>
>C# and Java trade incompatibility and the inability to easily integrate with C/C++ for the additional productivity and security.  D trades incompatibility for.. incompatibility.  Programming in D is just as unsafe as programming in C and C++, without the support of Microsoft and other 3rd parties to provide huge quantities of high level libraries and a powerful integrated environment.  D is unsafe by design, just as C and C++ were, but the difference is that this is 2006, and not the 70's, 80's, or 90's.
>
>The choice one is left with is to either program in a safe language and accept the overhead of the JIT, or use C/C++ with it's large existing base of tools and code other things in C# or Java.  One wonders why this is so, since C# has unsafe capabilities.. and CSecured offers safe C programming capabilities.  How long should we have to wait for a safe systems level language.. till microsoft releases their Singularity project and their Bartok compiler?
>
>------------
>
>The first two issues make much of the remaining critique irrelevant.  Once you have a singel showstopper, additional issues don't really make any difference. However I'll list them anyway.
>
>- Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
>
>- No stable standard.  Importance...  MEDIUM
>
>- Difficult to control what is garbage collected and what is not.  Garbage collection performance.  Garbage collection violates C++'s "zero overhead" rule where any performance overhead is at the programmers explicit discression. Importance...   MEDIUM
>
>- Not open source.    Importance... HIGH
>
>- Very small library base.   Importance... HIGH
>
>----------------------------------------------------------
>
>A modest suggestion, were I to try to introduce a new language which I intended to be not only clean and simple, but "popular" and widely used as well would be to squarely address the first three issues above.
>
>C++ provided a translator.  The original versions of C++ were able to output C code which would compile on any ordinary C compiler.  Likewise, the idea that C headers could simply be directly included in a C++ language file, and "it just worked" allows any C code to be used in a C++ program.. a feature that all C++ programmers use today.
>
>Finally, C and C++ code code be easily mixed within a single project, another feature of C++ that is used today.  Since C++ can consume any C header, and in most cases C can understand the ABI of C++ with the extern "C" {} wrapper, it's possible to go in both directions.
>
>All this being said, I would really like to see a language like D succeed, because I need the features it has.  But I can't abandon my C and C++ libraries, and I am not about to commit to coding wrappers for them, nor forgoing using my current programming environment and debugging tools.  When I adopted C++ 20 years ago, I didn't need to do this.  C++ integrated well with my tools and existing libs (the exception being the debugger of course).  But overall it was a good citizen in the overall world of C/C++ code.. it played nicely.  The same can not be said of D, C#, or Java, and D doesn't have the other benefits of C# or Java.
>
>Until D addresses these issues, it will be nothing more than a niche language offering syntactic cleanliness and interesting features to a few faithful, but largely ignored by the rest of the programming world.
>
>
>
>
>
>
>
>
>
>
>
>

In article <e4cgup$2te2$1@digitaldaemon.com>, Bill Baxter says...
>
>In article <e4ca0r$2hvj$1@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;
}
}

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.  

Those are good parallels, and it's good you brought that up. Working C++ legacy code is not going away and is not going to be translated to D. What will happen is *new* code will be done in D.

Paulo Herrera wrote:
> I apologize if part of this email is off topic in this thread.

I think it is on topic and a valuable addition to this thread.

Don Clugston wrote:

>> About native libraries
>> ----------------------
>> I think the way to go is to create QUALITY native D libraries. I think we usually overestimate the cost of porting/developing native libraries.
> 
> I agree. When porting a library
> (a) there isn't any algorithm development (not much 'thinking' time required);
> (b) it's very easy to test (you can run test cases against the original version);
> (c) the D version is frequently greatly superior to the original.

Hmm. Is there a 'canonical' Fortran numerics library with a solid test suite that could be translated to D as a showcase project?

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

have you any idea of how templates are generated and "instanciated"
what should the compiler do at this step? (please the describe the low-level part a little bit more detailed)

> // 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");

calling methods and instanciat classes through strings?
this is joke, or? (use the COM interface)

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

is this your idea of an clean integration? (what does clean mean in your world)

ciao dennis

btw: how many years do you code c/c++?