www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A gentle critque..

reply Ben Cooley <Ben_member pathlink.com> writes:
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/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

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

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.
May 14 2006
next sibling parent reply James Pelcis <jpelcis gmail.com> writes:
Ben Cooley wrote:

 - 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.
True. This has been discussed before, but has been rejected intentionally. We don't want every D compiler to end up being a C compiler, too.
 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. 
C doesn't have classes, so I assume you mean C++. While D does follow the C ABI, it doesn't follow the C++ one. I'm also surprised that you mentioned COM, since D can use that, too.
 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.
Making a library using extern (C) should do that.
 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.
While there are a few things that can't be done, most can. If you give us a specific problem, I'm sure something can be done about it.
 Provides no additional support for safe programming vs. C/C  Importance: HIGH
 ---------------------------------------------
 

 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

 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?
D will let you do whatever unsafe actions you want, but that doesn't mean you need to use them. For example, things like pointers and gotos still exist, but are not normally used. The idea is to give the functionality to those who can use it, but try to keep everyone else (like me) from shooting themselves in the foot.
 - Inability to integrate with visual studio.  No good IDE.. Importance...  
HIGH
There was a project to integrate D with Visual Studio. I'm not sure what the current status is, but you can probably find it if you look. As for the "no good IDE," that's being worked on right now. Try looking at http://www.dsource.org.
 - No stable standard.  Importance...  MEDIUM
There will be a stable standard as soon as we hit 1.0.
 - 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
You can allocate memory the C way with malloc if you want to. Anything allocated that way won't be garbage collected.
 - Not open source.    Importance... HIGH
The front end and the standard library are open source. There is also a project that links it directly into GCC. What more do you want?
 - Very small library base.   Importance... HIGH
You do have a point here, but that it being worked. Once again, look at http://www.dsource.org
 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.
Yes, and D can understand D code, too! You don't even need an extern (D).
 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

 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.
 
D may be a niche language right now, but it is far more popular than it used to be. Take a look at the TIOBE ranking, for example.
May 14 2006
next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
James Pelcis wrote:
 
 True.  This has been discussed before, but has been rejected
 intentionally.  We don't want every D compiler to end up being a C
 compiler, too.
 
This has always been a sore spot with me and D. There is A LOT of C/C++ code out there to leverage off of, and to me it is beyond inconvenient to require translation of all of those headers. Also, rewriting all of the code with a handful of D developer seems like insanity to me. That said, the two known D compilers are also C++ compilers (or at least share backends with C++ compilers). What a handy coincidence. I'd say that being able to link against C++ code shouldn't be part of the D spec, at least not permanently, but being able to link against C++ code should be supported by current D compilers just to get things moving for D. Then maybe someday compiler writers will save some effort by ditching C++ support because no one will use C++ anymore. I'm probably rehashing old arguments, but this matters to me. Also, it would be nice to have some links to those old arguments. Normally I'd find them myself, but this topic has proven itself a difficult search (at least with Thunderbird). Oh and whatever happened to all of those C header to D translation projects? Did people run into some sort of fundamental law of the universe that made it impossible, or was it just difficult enough to discourage everyone for a couple years?
May 14 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Chad J wrote:
 That said, the two known D compilers are also C compilers (or at least
 share backends with C compilers).  What a handy coincidence.  I'd say
 that being able to link against C code shouldn't be part of the D
 spec, at least not permanently, but being able to link against C code
 should be supported by current D compilers just to get things moving for
 D.  Then maybe someday compiler writers will save some effort by
 ditching C support because no one will use C anymore.
D can link against C code right now, it just will not compile C code.
May 14 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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. If it is actually easier to convert all of the C plus plus headers to D "headers" by hand than by creating some automated mechanism in the compiler, then OK, no full automated conversion. I find that hard to believe though. I am thinking game creation middleware for myself. This would involve hand translating a whole bunch of stuff, just to try it out. I may not even use the results for very long. I suppose I could code in C plus plus to try stuff out, but then I'm doing C plus plus coding and not D coding, and that's just about as bad as the header conversion (for me anyways). Then if the maintainers of a C plus plus library change the library, the D wrappers become outdated and need fixing. 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.
May 15 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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.
This isn't a "just because", C++ is known to be excessively hard to compile right, and one of the goals of D is to be easy to compile, to make sure you actually get compilers that are standard compliant and produce correct code within a sensible timeframe. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Lars Ivar Igesund wrote:
 
 This isn't a "just because", C++ is known to be excessively hard to compile
 right, and one of the goals of D is to be easy to compile, to make sure you
 actually get compilers that are standard compliant and produce correct code
 within a sensible timeframe.
 
Like I said, I wouldn't expect it to be part of the D spec. It could be just some sort of temporary thing that serves its purpose while C plus plus gets phased out of existence. I think D would win over C plus plus programmers much more quickly if it made the use of their old code as easy as possible. D, After winning the same massive popularity as C plus plus has enjoyed, would then no longer need such a capability.
May 15 2006
prev sibling parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e49cu3$13gk$1 digitaldaemon.com>, Lars Ivar Igesund says...
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.
This isn't a "just because", C++ is known to be excessively hard to compile right, and one of the goals of D is to be easy to compile, to make sure you actually get compilers that are standard compliant and produce correct code within a sensible timeframe.
That's certainly a good reason. However, it doesn't help me or any other programmer out in the real world which have to deal with very large quantities of frequently updated c and c plus plus third party libraries. D's role right now is as an enthusiast language for closed world small scale projects which can be written by hand converting existing c headers. Is this the ultimate intent of this language? I would say that a "header compiler" that just compiles both C and C plus plus headers into a format directly useable by D, and modifications to D such that it can easily use foreign C plus plus object types would be all that I would need.. along with the ability for the D compiler to produce output that could be linked and debugged with existing C and C plus plus compilers on linux and windows.
May 15 2006
parent Walter Bright <newshound digitalmars.com> writes:
Ben Cooley wrote:
 That's certainly a good reason.  However, it doesn't help me or any other
 programmer out in the real world which have to deal with very large quantities
 of frequently updated c and c plus plus third party libraries.
 
 D's role right now is as an enthusiast language for closed world small scale
 projects which can be written by hand converting existing c headers.  Is this
 the ultimate intent of this language?
 
 I would say that a "header compiler" that just compiles both C and C plus plus
 headers into a format directly useable by D, and modifications to D such that
it
 can easily use foreign C plus plus object types would be all that I would
need..
 along with the ability for the D compiler to produce output that could be
linked
 and debugged with existing C and C plus plus compilers on linux and windows.
D, right now, *can* link with existing C and C++ compiler generated code on linux and windows. It can also access C++ generated code that conforms to "COM" programming conventions. For an example of how D connects with C code, see the std.zlib support in the phobos standard library.
May 15 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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?
May 15 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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.
May 15 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
May 15 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
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.
May 15 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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.
May 15 2006
parent Dave <Dave_member pathlink.com> writes:
In article <e4aoo6$2st8$2 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.
May 15 2006
prev sibling parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4aohg$2st8$1 digitaldaemon.com>, Dave says...
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.
There are several full parsers out there available today. The GCC frontend for C++ is one.. it's used in GCC-XML. Another would be the elsa parser, which seems to do a fairly good job on our massive codebase, though we do have to macro define several linux and microsoft specific additions. Parsing is not the most difficult aspect, it's actually providing in-language facilities in D to utilize the constructs in Cpp. For this facility, you would generally need to integrate a Cpp compiler into the D compiler. Sure this would be an ugly hack, but such is life. The advantage would be that the D compiler could call the Cpp compiler to instantiate cpp code it needed to integrate Cpp constructs. The syntax in D for accessing Cpp classes, macros, and templates need not be particularly elegant, just not needlessly difficult. You wouldn't need to have D pretend that a C++ class was a D class, or have D conform to C++ syntax... merely make it possible to instantiate classes, templates, use macros, and do what you need to do with an external library without having to re-code it or spend weeks creating wrappers. If you would like to see how such a convergence would work, take a look at "managed C++". With .NET, microsoft faced the same problem. How do you get people to migrate to .NET when they have large quantities of code written in C and C++? Microsofts answer was the "IJW" philosophy. You can take any C/C++ code and simply compile it in .NET, then add .NET specific constructs to make the C++ code play nice in the .NET world. You do not need to recode your it should have in my opinion), but it did make Cpp play nice with .NET and that was very important for the adoption of .NET.
May 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ben Cooley wrote:
 If you would like to see how such a convergence would work, take a look at
 "managed C++".  With .NET, microsoft faced the same problem.  How do you get
 people to migrate to .NET when they have large quantities of code written in C
 and C++?  Microsofts answer was the "IJW" philosophy.  You can take any C/C++
 code and simply compile it in .NET, then add .NET specific constructs to make
 the C++ code play nice in the .NET world.  You do not need to recode your


 it should have in my opinion), but it did make Cpp play nice with .NET and that
 was very important for the adoption of .NET.
What managed C++ is is a bunch of extensions added to Microsoft's existing C++ compiler. That's what enables it to compile C++ - it already is a C++ compiler. accessible from C++. That's good for enticing people to migrate to .net,
May 15 2006
parent reply sailormoontw <sailormoontw_member pathlink.com> writes:
In article <e4bk4o$va0$1 digitaldaemon.com>, Walter Bright says...
What managed C++ is is a bunch of extensions added to Microsoft's 
existing C++ compiler. That's what enables it to compile C++ - it 
already is a C++ compiler.


accessible from C++. That's good for enticing people to migrate to .net, 

You can make DMC++ works like the managed C++, and then the relation of DMC++ code with DMC++ in the middle.
May 15 2006
parent Walter Bright <newshound digitalmars.com> writes:
sailormoontw wrote:
 In article <e4bk4o$va0$1 digitaldaemon.com>, Walter Bright says...
 What managed C++ is is a bunch of extensions added to Microsoft's 
 existing C++ compiler. That's what enables it to compile C++ - it 
 already is a C++ compiler.


 accessible from C++. That's good for enticing people to migrate to .net, 

You can make DMC++ works like the managed C++, and then the relation of DMC++ code with DMC++ in the middle.
It's technically possible, but it's just not very exciting :-(
May 15 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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.
 If it is actually easier to convert all of the C plus plus headers to D
 "headers" by hand than by creating some automated mechanism in the
 compiler, then OK, no full automated conversion.  I find that hard to
 believe though.
To properly convert C headers to D you really need a partial C compiler that generates D code, which is non-trivial. C++ header conversion is another thing entirely, and it simply isn't possible in any reasonable or portable manner. If you're truly interested in auto-conversion of D headers, why not create the tool yourself? There are open source C front ends available which should make for a good starting point.
 I am thinking game creation middleware for myself.  This would involve
 hand translating a whole bunch of stuff, just to try it out.  I may not
 even use the results for very long.  I suppose I could code in C plus
 plus to try stuff out, but then I'm doing C plus plus coding and not D
 coding, and that's just about as bad as the header conversion (for me
 anyways).  Then if the maintainers of a C plus plus library change the
 library, the D wrappers become outdated and need fixing.
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? Sean
May 15 2006
parent reply Sean Kelly <sean f4.ca> writes:
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
May 15 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
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.
May 15 2006
parent Mike Parker <aldacron71 yahoo.com> writes:
Chad J wrote:
 
 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.
It's safe to say that it's technically infeasible to do. But the other argument also has merit. Anything Walter builds into the compiler, or distributes with it, will be perceived as part of D whether it is in the spec or not. It doesn't matter that the perception is wrong. If people believe it, that's all it takes. Having a tool hosted by a third party on another site is altogether different. But because of the complexity, don't expect Walter to do it anonymously or otherwise. It's a horrid misapplication of resources.
May 15 2006
prev sibling next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Chad J wrote:

True.  This has been discussed before, but has been rejected
intentionally.  We don't want every D compiler to end up being a C
compiler, too.
This has always been a sore spot with me and D. There is A LOT of C/C code out there to leverage off of, and to me it is beyond inconvenient to require translation of all of those headers. Also, rewriting all of the code with a handful of D developer seems like insanity to me.
If you use a tool to help you, translating C headers is not THAT bad. Translating C++ headers is trickier, but can be done too if needed... I think that D has it slightly easier than some other languages, since it only needs to provide an import module - not any wrapper stubs, etc. It's one of the clear language decisions of D to break the source level compatibility with C, and C++, and even with older versions of D itself. If you need C compatibility, then C++ is a better choice. If you need C++ compatibility, then even Objective-C could be the better choice. But it is still easier to link to C code in D, than what it is wih Java. You don't need to write or generate the JNI (or CNI) stubs, and so on...
 That said, the two known D compilers are also C compilers (or at least
 share backends with C compilers).  What a handy coincidence.  I'd say
 that being able to link against C code shouldn't be part of the D
 spec, at least not permanently, but being able to link against C code
 should be supported by current D compilers just to get things moving for
 D.  Then maybe someday compiler writers will save some effort by
 ditching C support because no one will use C anymore.
AFAIK, the support for linking against C libraries is a huge part of D. For instance, the Phobos std D library uses a lot of the std C library ? Not being able to link with "C" means *no* external functions at all... (those externals can be written in anything, if they export a "C" API) And for a language that supports inline assembler, it would be a bit strange to drop support for linking to "portable assembler" (aka. C) ?
 [...]
 Oh and whatever happened to all of those C header to D translation
 projects?  Did people run into some sort of fundamental law of the
 universe that made it impossible, or was it just difficult enough to
 discourage everyone for a couple years?
Most of us translated the headers we needed, and got on with coding... Like someone said, 100% for all cases is hard - but it does like 90% ? There are several tools available, depending on what type that you like. It's a "known bug" with DMD, that such a tool isn't bundled by default. I did a perl hack that has worked OK (for me) for translating several large library headers from C to D, maybe I should bundle it with GDC ? --anders
May 15 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Anders F Björklund wrote:
 If you use a tool to help you, translating C headers is not THAT bad.
 Translating C++ headers is trickier, but can be done too if needed...
 I think that D has it slightly easier than some other languages, since 
 it only needs to provide an import module - not any wrapper stubs, etc.
Is there a good tool for C plus plus to C to D translation?
 But it is still easier to link to C code in D, than what it is wih Java.
 You don't need to write or generate the JNI (or CNI) stubs, and so on...
Haha, so true.
 AFAIK, the support for linking against C libraries is a huge part of D.
 For instance, the Phobos std D library uses a lot of the std C library ?
 Not being able to link with "C" means *no* external functions at all...
 (those externals can be written in anything, if they export a "C" API)
 
 And for a language that supports inline assembler, it would be a bit 
 strange to drop support for linking to "portable assembler" (aka. C) ?
I think I confused the term "linking" with... I don't even know what to call it then. C plus plus integration maybe.
 Most of us translated the headers we needed, and got on with coding...
 Like someone said, 100% for all cases is hard - but it does like 90% ?
 There are several tools available, depending on what type that you like.
 
 It's a "known bug" with DMD, that such a tool isn't bundled by default.
 I did a perl hack that has worked OK (for me) for translating several 
 large library headers from C to D, maybe I should bundle it with GDC ?
 
 --anders
I'd probably be pretty happy with 90-95% C plus plus header conversion. I'd like to see that perl hack. Is it online somewhere? I remember trying SWIG to get some C plus plus to D conversion going on, but that setup didn't work very well. Required a lot of work just to use it. Cure is worst than the disease sort of thing. I noticed an h2d project on dsource. But I think that only worked on linux, or something. For some reason I wasn't able to even try it. I don't remember seeing any tools of this kind that were written in D. Kind of unfortunate, probably makes it difficult to pool effort out of D programmers for something that isn't written in D. Any other tools I should look at?
May 15 2006
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Chad J wrote:

 Translating C++ headers is trickier, but can be done too if needed...
Is there a good tool for C plus plus to C to D translation?
Not really, and it's a two-step process. First you need to export all the C++ methods as "C" functions. Then you need to write at least an import module, and probably a class wrapper too, for all those exported procedural functions ?
 I think I confused the term "linking" with... I don't even know what to 
 call it then.  C plus plus integration maybe.
Sorry, the "dropping of the plusses" added some confusion there. D does have linkage with C functions (minus vectors, and some other advanced things that C extensions offers), but *not* for C++. So the only way to link with C++ is to first: export "C" { }
 I'd like to see that perl hack.  Is it online somewhere?
http://www.algonet.se/~afb/d/h2d.pl There is no parsing and no understanding, it just searches/replaces. It does try to use the C #defines, but sometimes it gets really confused. The way I use it is that I run it on the C headers, and then I run a "diff" to fix the parts where it screwed up. Some parts, like tricky macros, need to be rewritten from scratch. So it's not really an automated solution, just a little "crutch" (see the SDL and GL/AL headers from that same URL, for more examples)
 I remember trying SWIG to get some C plus plus to D conversion going on, 
 but that setup didn't work very well.  Required a lot of work just to 
 use it.  Cure is worst than the disease sort of thing.
SWIG is nice (when it works), but it's a huge project in itself...
 I noticed an h2d project on dsource.  But I think that only worked on 
 linux, or something.  For some reason I wasn't able to even try it.
It has some really nasty C++ dependencies. Tried to use it, but...
 I don't remember seeing any tools of this kind that were written in D. 
 Kind of unfortunate, probably makes it difficult to pool effort out of D 
 programmers for something that isn't written in D.
I think that such a tool would be a good "exercise" for D, and could become highly useful too - just like Build has become ? But I started out with the missing GUI and IDE instead, myself. --anders
May 15 2006
prev sibling parent BCS <BCS pathlink.com> writes:
Chad J wrote:
 James Pelcis wrote:
 
True.  This has been discussed before, but has been rejected
intentionally.  We don't want every D compiler to end up being a C
compiler, too.
[...]
 
 That said, the two known D compilers are also C compilers (or at least
 share backends with C compilers).
dmd under windows has a "header generation" feature that will make D's replacement to a .h file. Further more it shares the backend ()and thus the frontend/backend interface with dmc (Walter's c/c++ compiler). I'm wondering, where is the "header generation" going on? Is it close enough to the front/back interface that the C compiler could be stacked on top of it? This would allow automatic generation of headers from .c or .h files.
May 15 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Technical alert: it seems that the (plus plus) disappears from your
post. hence C++ (see plus plus) appears as C (see).

It's specially funny with the comment:

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.
Yes, and D can understand D code, too! You don't even need an extern (D).
He's talking about C and C++ (see and see plus plus) not C and C (see and see)!!!! James Pelcis wrote:
 
 Ben Cooley wrote:
 
 
- 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.
True. This has been discussed before, but has been rejected intentionally. We don't want every D compiler to end up being a C compiler, too.
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. 
C doesn't have classes, so I assume you mean C. While D does follow the C ABI, it doesn't follow the C one. I'm also surprised that you mentioned COM, since D can use that, too.
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.
Making a library using extern (C) should do that.
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.
While there are a few things that can't be done, most can. If you give us a specific problem, I'm sure something can be done about it.
Provides no additional support for safe programming vs. C/C  Importance: HIGH
---------------------------------------------


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

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?
D will let you do whatever unsafe actions you want, but that doesn't mean you need to use them. For example, things like pointers and gotos still exist, but are not normally used. The idea is to give the functionality to those who can use it, but try to keep everyone else (like me) from shooting themselves in the foot.
- Inability to integrate with visual studio.  No good IDE.. Importance...   HIGH
There was a project to integrate D with Visual Studio. I'm not sure what the current status is, but you can probably find it if you look. As for the "no good IDE," that's being worked on right now. Try looking at http://www.dsource.org.
- No stable standard.  Importance...  MEDIUM
There will be a stable standard as soon as we hit 1.0.
- 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
You can allocate memory the C way with malloc if you want to. Anything allocated that way won't be garbage collected.
- Not open source.    Importance... HIGH
The front end and the standard library are open source. There is also a project that links it directly into GCC. What more do you want?
- Very small library base.   Importance... HIGH
You do have a point here, but that it being worked. Once again, look at http://www.dsource.org
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.
Yes, and D can understand D code, too! You don't even need an extern (D).
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

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.
D may be a niche language right now, but it is far more popular than it used to be. Take a look at the TIOBE ranking, for example.
May 14 2006
parent Ben Cooley <Ben_member pathlink.com> writes:
In article <e4943e$hke$1 digitaldaemon.com>, Hasan Aljudy says...
Technical alert: it seems that the (plus plus) disappears from your
post. hence C++ (see plus plus) appears as C (see).
It did seem a bit strange.
May 15 2006
prev sibling parent reply Ben Cooley <Ben_member pathlink.com> writes:
 - 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.
True. This has been discussed before, but has been rejected intentionally. We don't want every D compiler to end up being a C compiler, too.
Why not. C and C++ compilers seem to be particularly common. Digital Mars happens to have one, so does GCC, and it's even independently maintained. It doesn't matter. All proponents of marginal languages make similar arguments about the goalfor some sort of purity. It seems like this is the common reason why marginal languages are created in the first place, but it's also the primary reason why they fail to become mainstream languages. Think about this.. if C++ had followed the same path, it would also have failed. The utility of the "It just works" paradigm in C to C++ integration and conversion made the success of C++ possible. I would generally say that any successful competitor to C++ and C would: 1. Need to directly parse C and C++ headers. 2. Need to integrate with C++ (ABI). 3. Need to be able to be used in a mixed project (C/C++/D) and arbitrarily mix and match C, C++, and D objects. My motivation for posting this critique is not to criticize D.. which I happen to really like, but to vent my frustration that as it stands I will never actually be able to use it.
May 15 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ben Cooley wrote:

 - 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.
True. This has been discussed before, but has been rejected intentionally. We don't want every D compiler to end up being a C compiler, too.
Why not. C and C++ compilers seem to be particularly common. Digital Mars happens to have one, so does GCC, and it's even independently maintained. It doesn't matter. All proponents of marginal languages make similar arguments about the goalfor some sort of purity. It seems like this is the common reason why marginal languages are created in the first place, but it's also the primary reason why they fail to become mainstream languages.
I don't see a single sign of D "failing", although a fairly low number of active developers lead to a somewhat slow development of libraries and such. And currently there is no single person in the D community feeling that the need for such a tool is so great that they prioritize developing it. If you feel different, I urge you to do something about the situation, since I am quite sure it would be heartily welcomed (no sarcasm here, really).
 
 Think about this.. if C++ had followed the same path, it would also have
 failed. The utility of the "It just works" paradigm in C to C++
 integration and conversion made the success of C++ possible.
And this is one of the reasons for C++ getting into the mud in the first place.
 
 I would generally say that any successful competitor to C++ and C would:
 
 1. Need to directly parse C and C++ headers.
This would have been nice, but as is said is an almost impossible task unless you are willing to spend a huge amount of time.
 2. Need to integrate with C++ (ABI).
I don't see how this should be possible, the different C++ compilers don't agree about the ABI!
 3. Need to be able to be used in a mixed project (C/C++/D) and arbitrarily
 mix and match C, C++, and D objects.
This is possible as long as mangling and ABI otherwise match, but it requires everything to be compiled with the same toolchain, plus quite a lot of massaging for the C++ part.
 
 My motivation for posting this critique is not to criticize D.. which I
 happen to really like, but to vent my frustration that as it stands I will
 never actually be able to use it.
Hmm, this must be the first time a critique was not meant to criticize ... Seriously, have you tried to use D? What kind of libraries do you need? Are you aware of the fact that Java libraries actually might be possible convert to D with much less effort than whatever you try to do with C++? And what about dynamic linking/loading? This is usually considered a good practice, and it is eminently possible (just like in C and C++) to do in D. D have it's issues, and not being able to link in C++ (or understand C++ source) is not one of them, IMO. As I try to mention from time to time, D is already being used in several commercial projects, which in themselves will lead to more commercial D development. The spiral is going upwards, the speed it happens with is irrelevant. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
prev sibling next sibling parent reply Carlos <noone nowhere.com> writes:
- D is not C++ ... Importance: SIGH
- D cannot toast bread ... IMPORTANCE: SHOW-TOASTER
- D cannot prevent idiocy in programmers ... IMPORTANCE: FATAL

Charlie


Ben Cooley wrote:
 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/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

 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

 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.
 
 
 
 
 
 
 
 
 
 
 
 
May 14 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Carlos wrote:
 - D is not C++ ... Importance: SIGH
 - D cannot toast bread ... IMPORTANCE: SHOW-TOASTER
 - D cannot prevent idiocy in programmers ... IMPORTANCE: FATAL
 
 Charlie
 
 
 Ben Cooley wrote:
 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
 ---------------------------------------------


 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

 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


 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.
Dont be an ass. Ben, please don't be offended, most of us are nice people. ;-) ( I still love you Charlie ) -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
May 14 2006
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e48h8g$pk$1 digitaldaemon.com...
 I'll just list them and note their importance.  Anything witha
Anything with a ..?
 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.
While I agree that converting C headers is a pain, it's a small price to pay for keeping the complexity of the D spec down. In any case, using any language _except_ C/C++ means that you have to translate header files. If anything, this doesn't reflect a weakness with languages other than C/C++, but rather, an outdated standard imposed on all languages by C/C++. A much better means of disseminating code would be a language-agnostic interface definition file, which could easily be supported by all programming languages.
 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.
C++ doesn't have a unified ABI. Different compilers, and even different versions of the same compiler, can produce incompatible binary code. In addition, C does not have ABI compatibility with C++. C++ can produce C-compatible code, just as D can, but C cannot natively communicate with C++ code.
 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.
Enough with the "D is not C++" argument already. We've got it.
 No support for meta-programming or Macros   Importance:    SHOW-STOPPER
 ---------------------------------------------
 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.
What exactly are you missing?
 Provides no additional support for safe programming vs. C/C++  Importance: 
 HIGH
 ---------------------------------------------


 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

 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?
Blah blah blah.
 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.
Your first two showstoppers (or rather, your first three), are basically "D doesn't work with C++."
 - Inability to integrate with visual studio.  No good IDE.. Importance... 
 HIGH
No good IDE is a big problem, I'll agree with you.
 - No stable standard.  Importance...  MEDIUM
Considering the standard is _not even out of alpha yet_, I'm not sure how you can even consider this a "weakness."
 - 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
A problem in any GCed language. And in D, the GC can be turned off and custom memory allocators can be used for higher-performance code.
 - Not open source.    Importance... HIGH
Now you're just pulling stuff out of..... the air. The front-end is completely open-source; the back end is not, as it's also used in a commercial product. There is also GDC, a fully open-source implementation of D.
 - Very small library base.   Importance... HIGH
I'll definitely agree with you there, though the concerns about the library aren't exactly a new topic here.
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.
It's because C++ was designed, from the start, to be an extension of C. D's mantra is entirely different - it says "how can C/C++ be redesigned knowing what we know today?" Not "how much more crap can we add to an overly-bloated language and still manage not to break decades worth of legacy code?"
 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.
blah blah blah
 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


 or Java.
So don't use D then. Just stay with C++.
 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.
And entirely in yor opinion. Which seems to be _incredibly_ biased towards C++.
May 14 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 15 May 2006 00:16:16 +0000 (UTC), Ben Cooley wrote:

 - Inability to access C/C++ include files...  Importance:   SHOW-STOPPER
 --------------------------------------------
 
 C++ can do this, D can not.
What! You mean that C++ (a superset of C) can actually access both C and C++ include files? Who would have guessed that!? Fortran and Java can't use C/C++ includes either. I think the sky is falling.
 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.
But all joking aside, it just occurred to me that Digitalmars already has a tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm wondering if Walter could provide a new utility that can help us automate translation of C/C++ headers into D source code?
 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.
Prior C existing, programmers used other entrenched languages (of course) and yet C still managed to take root? So even though C could not access the source code of those entrenched languages, it become popular. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 15/05/2006 12:39:04 PM
May 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 But all joking aside, it just occurred to me that Digitalmars already has a
 tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm
 wondering if Walter could provide a new utility that can help us automate
 translation of C/C++ headers into D source code?
There's no way to do that with C++ - just take a look at any Boost headers :-). It is possible to do a 90% automatic translation of C headers.
May 14 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 14 May 2006 23:22:56 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 But all joking aside, it just occurred to me that Digitalmars already has a
 tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm
 wondering if Walter could provide a new utility that can help us automate
 translation of C/C++ headers into D source code?
There's no way to do that with C++ - just take a look at any Boost headers :-). It is possible to do a 90% automatic translation of C headers.
May I repeat a portion of my post please ... "a new utility that can **help** us automate translation of C/C++ headers into D source code" I know that 100% automated translation is not practical. However, as DigitalMars already has a C/C++ parser that works, I was thinking that a tool based on that parser to created a best-effort translation and highlighted that which needs human effort might be a useful addition to the D tool set. Whatever you have now as a C/C++ parser has got to be better than writing a new one from scratch. I'm not asking for the source code for that parser, just a tool that would output something that could be tweaked into D code by either (or both) another tool or person. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 15/05/2006 4:47:55 PM
May 14 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:
 May I repeat a portion of my post please ...
 
     "a new utility that can **help** us automate
      translation of C/C++ headers into D source code"
 
 I know that 100% automated translation is not practical. However, as
 DigitalMars already has a C/C++ parser that works, I was thinking that a
 tool based on that parser to created a best-effort translation and
 highlighted that which needs human effort might be a useful addition to the
 D tool set. Whatever you have now as a C/C++ parser has got to be better
 than writing a new one from scratch. I'm not asking for the source code for
 that parser, just a tool that would output something that could be tweaked
 into D code by either (or both) another tool or person.
One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image. The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.
May 15 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:

 One of my concerns about me writing such a tool is that people will have 
 too high expectations of it, and when it fails to deliver 100% automated 
 conversion, it'll give the rest of D a bad image.
Adding it as a part of the compiler might be tricky to do "right"... People will still need such a tool, though ? As 90% is more than "0%". But I can see the problems with bundling as a "silver bullet" package.
 The first thing someone new to D will do is try to run the converter 
 across all their C header files. The converter will fail miserably. 
 They'll just dismiss D as a buggy piece of ****.
Funny, that's about what happened with Ddoc and my own D files :-) But I didn't just dismiss Ddoc because of that, as it had potential ? (even if I'm still using Doxygen, because it has some neat features) --anders
May 15 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 
 May I repeat a portion of my post please ...

     "a new utility that can **help** us automate
      translation of C/C++ headers into D source code"

 I know that 100% automated translation is not practical. However, as
 DigitalMars already has a C/C++ parser that works, I was thinking that a
 tool based on that parser to created a best-effort translation and
 highlighted that which needs human effort might be a useful addition 
 to the
 D tool set. Whatever you have now as a C/C++ parser has got to be better
 than writing a new one from scratch. I'm not asking for the source 
 code for
 that parser, just a tool that would output something that could be 
 tweaked
 into D code by either (or both) another tool or person.
One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image. The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.
Don't include with dmd. Just put it on dsource, disguised as "yet another conversion tool project" ;) or something like that. ok, dsource is a bad idea, because the tool won't be open source. Still, you can create a lame page on geocities and put the tool up for download. Don't say it's Walter Bright, just pick a random nick name.
May 15 2006
prev sibling next sibling parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e49b0t$11f0$1 digitaldaemon.com>, Walter Bright says...
Derek Parnell wrote:
 May I repeat a portion of my post please ...
 
     "a new utility that can **help** us automate
      translation of C/C++ headers into D source code"
 
 I know that 100% automated translation is not practical. However, as
 DigitalMars already has a C/C++ parser that works, I was thinking that a
 tool based on that parser to created a best-effort translation and
 highlighted that which needs human effort might be a useful addition to the
 D tool set. Whatever you have now as a C/C++ parser has got to be better
 than writing a new one from scratch. I'm not asking for the source code for
 that parser, just a tool that would output something that could be tweaked
 into D code by either (or both) another tool or person.
One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image. The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.
Hi Walter, Great work on D, by the way! I guess this post is just frustration that I will never actually be able to use it except in some smaller projects. About parsing headers.. I'm sure people would feel the same way about any C or C plus plus compiler. If it couldn't parse headers, it wouldn't be particularly useful. It's a tough row to hoe.. but well there you are when you decide to write an alternative to C and C plus plus. The ability to integrate easily with all the existing code out there is crtitically important. Speaking from personal scenario, the requirement that I wrap several hundred thousands of lines of existing code is a non-starter. It was difficult enough the first time I did it.. having to place extern "C" { } around all my C headers transitioning over to C plus plus in the 80's and 90's and fix various ideosyncracies between the C and C plus plus parsers. It's just completely impossible now. 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. If this were possible, I could simply begin to add D modules to my code base and start the gradual transition.. as I once did long ago with my C plus plus code. I would also like to add that the ability to clearly define certain regions of discretion and code policies help in large projects.
May 15 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Ben Cooley wrote:

 In article <e49b0t$11f0$1 digitaldaemon.com>, Walter Bright says...
Derek Parnell wrote:
 May I repeat a portion of my post please ...
 
     "a new utility that can **help** us automate
      translation of C/C++ headers into D source code"
 
 I know that 100% automated translation is not practical. However, as
 DigitalMars already has a C/C++ parser that works, I was thinking that a
 tool based on that parser to created a best-effort translation and
 highlighted that which needs human effort might be a useful addition to
 the D tool set. Whatever you have now as a C/C++ parser has got to be
 better than writing a new one from scratch. I'm not asking for the
 source code for that parser, just a tool that would output something
 that could be tweaked into D code by either (or both) another tool or
 person.
One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image. The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.
Hi Walter, Great work on D, by the way! I guess this post is just frustration that I will never actually be able to use it except in some smaller projects. About parsing headers.. I'm sure people would feel the same way about any C or C plus plus compiler. If it couldn't parse headers, it wouldn't be particularly useful. It's a tough row to hoe.. but well there you are when you decide to write an alternative to C and C plus plus. The ability to integrate easily with all the existing code out there is crtitically important.
I guess that Walter would know if it was technically feasible, having developed the current D reference compiler, and the first native commercial C++ compiler. If he don't want to do it, I don't see how that would hinder you from trying to get this working with the GDC and G++ sources, though. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Ben Cooley wrote:
 In article <e49b0t$11f0$1 digitaldaemon.com>, Walter Bright says...
 
Derek Parnell wrote:

May I repeat a portion of my post please ...

    "a new utility that can **help** us automate
     translation of C/C++ headers into D source code"

I know that 100% automated translation is not practical. However, as
DigitalMars already has a C/C++ parser that works, I was thinking that a
tool based on that parser to created a best-effort translation and
highlighted that which needs human effort might be a useful addition to the
D tool set. Whatever you have now as a C/C++ parser has got to be better
than writing a new one from scratch. I'm not asking for the source code for
that parser, just a tool that would output something that could be tweaked
into D code by either (or both) another tool or person.
One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image. The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.
Hi Walter, Great work on D, by the way! I guess this post is just frustration that I will never actually be able to use it except in some smaller projects. About parsing headers.. I'm sure people would feel the same way about any C or C plus plus compiler. If it couldn't parse headers, it wouldn't be particularly useful. It's a tough row to hoe.. but well there you are when you decide to write an alternative to C and C plus plus. The ability to integrate easily with all the existing code out there is crtitically important.
please note, one of the original motivations and explicit goals of D is to break the never ending backwards compatibility issue. D is intentionally not compatible with C++. It's not a side effect of developing a new language, it's an explicitly stated goal!! Tough .. Don't try to convert millions of lines of C++ code to D, that's just not practical.
 
 Speaking from personal scenario, the requirement that I wrap several hundred
 thousands of lines of existing code is a non-starter.  It was difficult enough
 the first time I did it.. having to place extern "C" { } around all my C
headers
 transitioning over to C plus plus in the 80's and 90's and fix various
 ideosyncracies between the C and C plus plus parsers.  It's just completely
 impossible now.
 
 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.  
 
 If this were possible, I could simply begin to add D modules to my code base
and
 start the gradual transition.. as I once did long ago with my C plus plus code.
 
 I would also like to add that the ability to clearly define certain regions of

 discretion and code policies help in large projects.
 
 
May 15 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
May 15 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4an5r$2reb$1 digitaldaemon.com>, Walter Bright says...
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.
Hmmm... well I can certainly sympathize because I don't want to use DMD without that capability either. ;-) Truth is I can't. But my advice to those other implementations would be to just get cracking. The GCC implementation wouldn't have too much trouble For the others there are a variety of free versions of full CPP compilers out there. An alternative would be to compile C and CPP headers to a C/CPP pcode format which could be accessed by the D cpp interface. Part of the D compiler would comprehend certain foreign cpp constructs as part of the basic D compiler, while a simpler external parsing tool would actually generate a cpp pcode file.
May 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ben Cooley wrote:
 In article <e4an5r$2reb$1 digitaldaemon.com>, Walter Bright says...
 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.
Hmmm... well I can certainly sympathize because I don't want to use DMD without that capability either. ;-) Truth is I can't. But my advice to those other implementations would be to just get cracking. The GCC implementation wouldn't have too much trouble For the others there are a variety of free versions of full CPP compilers out there.
g++ is the only free full C++ compiler out there.
 An alternative would be to compile C and CPP headers to a C/CPP pcode format
 which could be accessed by the D cpp interface.  Part of the D compiler would
 comprehend certain foreign cpp constructs as part of the basic D compiler,
while
 a simpler external parsing tool would actually generate a cpp pcode file.
There is no such thing as a simple C++ parsing tool. That's one of the huge problems C++ has - you need a full compiler just to parse it. It took 10 years for the various vendors just to get the preprocessor to be standard compliant.
May 15 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4bjhk$tr8$1 digitaldaemon.com>, Walter Bright says...
Ben Cooley wrote:
 In article <e4an5r$2reb$1 digitaldaemon.com>, Walter Bright says...
 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.
Hmmm... well I can certainly sympathize because I don't want to use DMD without that capability either. ;-) Truth is I can't. But my advice to those other implementations would be to just get cracking. The GCC implementation wouldn't have too much trouble For the others there are a variety of free versions of full CPP compilers out there.
g++ is the only free full C++ compiler out there.
 An alternative would be to compile C and CPP headers to a C/CPP pcode format
 which could be accessed by the D cpp interface.  Part of the D compiler would
 comprehend certain foreign cpp constructs as part of the basic D compiler,
while
 a simpler external parsing tool would actually generate a cpp pcode file.
There is no such thing as a simple C++ parsing tool. That's one of the huge problems C++ has - you need a full compiler just to parse it. It took 10 years for the various vendors just to get the preprocessor to be standard compliant.
Elsa seems to do a pretty good job for us.. and we've got some pretty complicated template usage. But you really need little more than the sort of parser used to create documentation, or to view the class hierarchy. You don't need to parse any actual code, just definitions. Swig is a good example. As for the preprocessor, all C compilers come with their own already, so that's really not a major problem. A D pass to extract macros first, then a preprocessing pass by the real Cpp compiler, then a declaration parsing pass.
May 15 2006
parent Walter Bright <newshound digitalmars.com> writes:
Ben Cooley wrote:
 Elsa seems to do a pretty good job for us.. and we've got some pretty
 complicated template usage.  But you really need little more than the sort of
 parser used to create documentation, or to view the class hierarchy.  You don't
 need to parse any actual code, just definitions.  Swig is a good example.
I've never heard of Elsa, but I bet I can break it <g>.
 As for the preprocessor, all C compilers come with their own already, so that's
 really not a major problem.  A D pass to extract macros first, then a
 preprocessing pass by the real Cpp compiler, then a declaration parsing pass.
That might work, but it's quite a lashup.
May 15 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 Derek Parnell wrote:
 
 May I repeat a portion of my post please ...

     "a new utility that can **help** us automate
      translation of C/C++ headers into D source code"

 I know that 100% automated translation is not practical. However, as
 DigitalMars already has a C/C++ parser that works, I was thinking that a
 tool based on that parser to created a best-effort translation and
 highlighted that which needs human effort might be a useful addition 
 to the
 D tool set. Whatever you have now as a C/C++ parser has got to be better
 than writing a new one from scratch. I'm not asking for the source 
 code for
 that parser, just a tool that would output something that could be 
 tweaked
 into D code by either (or both) another tool or person.
One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image. The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.
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.
May 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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 :-(
May 15 2006
next sibling parent reply Ben Cooley <Ben_member pathlink.com> writes:
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 :-(
Could the language be extended to allow the non-translatable elements to simply be used "as is" by wrapping them with intrinsics as needed? In other words: import std.cpp; import msvc.cpp; include "mylib.h" .. .. .. // Intrinsic cpp new class function my_cpp_class = NewCppClass("MyClass", 100, "Parameter"); // Intrinsic cpp macro value const int MY_MACRO = CMacroValue("MY_MACRO"); // Intrinsic template instantiation my_cpp_template = NewTemplateClass("std::vector", "MyClass"); etc. The advantage of this is that, though it may not be pretty.. it's simple and it doesn't require you to wrap what could literally be thousands of headers. It also means that your links to the original code will not break unless the api breaks. If you want, you can build your wrapper using intrinsics instead of having to rewrite a header. But more importantly you can just use what you need, and directly call c functions and instantiate, call, and delete c classes and templates or access C or Cpp macros.
May 15 2006
parent dennis luehring <dl.soluz gmx.net> writes:
 In other words:
 
 import std.cpp;
 import msvc.cpp;
 
 include "mylib.h"
please stop talking about such ugly things... the discussion is long enough (i think) - we don't want an real c++ compiler in D (and for your ideas some is needed - if you understand it or not) or in an standart toolset around D - because the D syntax is near enough to C/C++
 The advantage of this is that, though it may not be pretty.. it's simple and it
 doesn't require you to wrap what could literally be thousands of headers.  It
 also means that your links to the original code will not break unless the api
 breaks.
all your handy and pretty ideas are nice to use but very hard (due to the mud code which is needed - its not an technical problem - its an phylosophical...) to implement Walter don't want to mutate the clean/simple/nice/fast D front/backend code into an C++ understanding between-the-worlds-compiler ... it is possible but only simple of your extension ideas will kill the clean (technical/phylosiphical) situation - and you will only understand the problem if you get more in contact with compiler development and language development and please - walter is one of the first full c++ compiler developers on the world ... try to understand his problems with your ideas "a flood of ideas don't help you to understand" btw: i think all your saying is just blabla - do you realy want to use D? - i don't think so (not only because of the cpp linkage problems) (if Cpp were linkable with D) - what are the other your other reasons to use D? ciao dennis
May 15 2006
prev sibling parent reply BCS <BCS_member pathlink.com> writes:
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.
May 15 2006
parent reply Bill Baxter <Bill_member pathlink.com> writes:
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
May 16 2006
next sibling parent reply Paulo Herrera <pauloh81 yahoo.ca> writes:
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. I apologize if part of this email is off topic in this thread. Paulo.
May 16 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Paulo Herrera wrote:
 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.
Welcome! There are quite a few of us here already. 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.
And Fortran takes numerics seriously. Unlike almost all of the more recent languages. D is the only recent general-purpose language I know of that takes numerics seriously (that's what initially attracted me to it).
 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.
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. D is a fantastic language for writing libraries in. IMHO, if we had even a small number of libraries with solid unit test coverage, everything else would start to look obsolete very quickly.
 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.
And .NET too.
 
 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.
 
 I apologize if part of this email is off topic in this thread.
 Paulo.
Right on topic, I would say. -Don.
May 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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?
May 16 2006
next sibling parent reply Paulo Herrera <pauloh81 yahoo.ca> writes:
Walter Bright wrote:
 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?
Do you have some idea in mind? For my work I need a good iterative (or fast sparse) linear solver. I used the Fortran SPARSKIT library in the past (http://www-users.cs.umn.edu/~saad/software/SPARSKIT/sparskit.html), but I found much more comprehensive libraries in other languages. For example, the MTJ Java library (http://rs.cipr.uib.no/mtj/. That is a very complete linear algebra library with dense and sparse matrix and vectors, and direct and iterative solvers. The library is very well designed and organized. Unfortunately, the performance of the pure Java version is not so good (see http://rs.cipr.uib.no/mtj/benchmark.html). MTJ can use native CBLAS and LAPACK, but that requires to "convince" Java to use those libraries (another example of problems with the use of different languages). If we can make a port of that library to D and show that it performs close to SPARSKIT, that would be a good demonstration of D capabilities for numerical computing. Paulo.
May 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Paulo Herrera wrote:
 Walter Bright wrote:
 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?
Do you have some idea in mind?
I am not familiar with the various Fortran libraries out there, so I have no specific one in mind.
 If we can make a port of that library to D and show that it performs 
 close to  SPARSKIT, that would be a good demonstration of D capabilities 
 for numerical computing.
Want to get started on it? <g>
May 16 2006
next sibling parent Roberto Mariottini <Roberto_member pathlink.com> writes:
In article <e4drmd$6q5$1 digitaldaemon.com>, Walter Bright says...

[...]
I am not familiar with the various Fortran libraries out there, so I 
have no specific one in mind.
FFTW (http://www.fftw.org/) is not written in fortran, but it's used by many fortran libraries. It could be a nice addition to D. Ciao --- http://www.mariottini.net/roberto/
May 16 2006
prev sibling parent reply Paulo Herrera <pauloh81 yahoo.ca> writes:
Walter Bright wrote:
 Paulo Herrera wrote:
 Walter Bright wrote:
 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?
Do you have some idea in mind?
I am not familiar with the various Fortran libraries out there, so I have no specific one in mind.
 If we can make a port of that library to D and show that it performs 
 close to  SPARSKIT, that would be a good demonstration of D 
 capabilities for numerical computing.
Want to get started on it? <g>
OK, I take the challenge. However, I'm pretty new to D so I'd like to ask some questions before starting. As someone else posted, most of numerical libraries in Fortran and C/C++ are based on BLAS and LAPACK. So, a first logic step is to evaluate if we should port those libraries to D. This weekend I took a look to the specification of those libraries (http://www.netlib.org/blas/). After going through the document I'm not sure what is the best way to write a similar library in a "D way". I will try to explain what I mean by "D way" .... I'm sure many people are familiar with those libraries, but I include a brief explanation below to make my question clear. Those libraries define functions to compute basic matrix/vector operations, such as: - x = y, where x and y are vectors - R = aAx, where A and R are matrices, a is a scalar, and x is a vector - r = aAx + by; where a and b are scalars, A is a matrix, and r, x and y are vectors. Since they were originally developed as a specification for old Fortran77 and C, the declaration of the routines that implement those operations look like: - x = y => void copy(T *x, T *y) - R = aAx => void mult0(T a, T *A, T *x, T *r), etc. Those declarations are not elegant and they are not easy to use. My first question is: Should we write a D library in that way to get best performance? I hope the answer is no, because that would be an advantage of D over other languages. I believe we should overwrite operators to make the notation as natural as possible. This is something that the designers of BLAS also faced about Fortran95 that includes array operations: "Some of the functions ... can be replaced by simple array expressions and assignments in Fortran95, without loss of convenience or performance(assuming a reasonable degree of optimization by the compiler)...." (in "Basic Linear Algebra Subprograms Technical (BLAST) Forum Standard", 2001, p. 26) My questions are: 1) Do you think it's possible to write vector and matrix classes with overloaded operators that perform as well as the primitive BLAS operations? What about temporary objects? 2) Do you think some of those operations can be accelerated by implementing them as part of the language (as described in future work in D) If yes, is there any time frame for those changes? 3) Since the type T on those expressions can change, what is the best way to implement those function without loosing performance? templates? Since in general people will use only one data type in their programs, could we use typedef or alias to get better performance? 4) Is there a real interest for this kind of libraries? Thanks, Paulo.
May 17 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Paulo Herrera wrote:
 Walter Bright wrote:
 Paulo Herrera wrote:
 Walter Bright wrote:
 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?
Do you have some idea in mind?
I am not familiar with the various Fortran libraries out there, so I have no specific one in mind.
 If we can make a port of that library to D and show that it performs 
 close to  SPARSKIT, that would be a good demonstration of D 
 capabilities for numerical computing.
Want to get started on it? <g>
OK, I take the challenge. However, I'm pretty new to D so I'd like to ask some questions before starting. As someone else posted, most of numerical libraries in Fortran and C/C++ are based on BLAS and LAPACK. So, a first logic step is to evaluate if we should port those libraries to D. This weekend I took a look to the specification of those libraries (http://www.netlib.org/blas/). After going through the document I'm not sure what is the best way to write a similar library in a "D way". I will try to explain what I mean by "D way" .... I'm sure many people are familiar with those libraries, but I include a brief explanation below to make my question clear. Those libraries define functions to compute basic matrix/vector operations, such as: - x = y, where x and y are vectors - R = aAx, where A and R are matrices, a is a scalar, and x is a vector - r = aAx + by; where a and b are scalars, A is a matrix, and r, x and y are vectors. Since they were originally developed as a specification for old Fortran77 and C, the declaration of the routines that implement those operations look like: - x = y => void copy(T *x, T *y) - R = aAx => void mult0(T a, T *A, T *x, T *r), etc. Those declarations are not elegant and they are not easy to use. My first question is: Should we write a D library in that way to get best performance? I hope the answer is no, because that would be an advantage of D over other languages. I believe we should overwrite operators to make the notation as natural as possible. This is something that the designers of BLAS also faced about Fortran95 that includes array operations: "Some of the functions ... can be replaced by simple array expressions and assignments in Fortran95, without loss of convenience or performance(assuming a reasonable degree of optimization by the compiler)...." (in "Basic Linear Algebra Subprograms Technical (BLAST) Forum Standard", 2001, p. 26) My questions are: 1) Do you think it's possible to write vector and matrix classes with overloaded operators that perform as well as the primitive BLAS
Not right now probably, but...
 operations? What about temporary objects?
...check out this thread regarding temporaries: http://www.digitalmars.com/d/archives/digitalmars/D/35949.html This hasn't been implemented (yet), but given Walter's comment looks promising. I'm assuming you agree this would be a great idea too.
 2) Do you think some of those operations can be accelerated by 
 implementing them as part of the language (as described in future work 
 in D) If yes, is there any time frame for those changes?
 3) Since the type T on those expressions can change, what is the best 
 way to implement those function without loosing performance?  templates? 
Yes.
   Since in general people will use only one data type in their programs, 
 could we use typedef or alias to get better performance?
Typedef or alias shouldn't make a difference, but may be a convenience.
 4) Is there a real interest for this kind of libraries?
I'm not a numerical programmer myself, so I'll gladly defer to the opinions of others, but I think there would be interest because there have been quite a few in that field participating in these NG's. There really seems to be great interest in a curly-brace language that "does numerics right" <g>
 
 Thanks,
 Paulo.
BTW - I downloaded this code to get an idea of 'raw' matrix performance: http://rs.cipr.uib.no/mtj/bench/JAVAGEMM.html and modified it to gather an avg. Here's what I get on a P4 2.2GHz, 512 KB L2, 512 MB RAM running FC5: GDC v0.17, using dmd v0.140 w/ GCC v4.0.2 (GDC is the D port for GCC) gdc -O3 -fomit-frame-pointer -funroll-loops -frelease dgemm.d -o dgemm Max N = 500 avg. mfs: 632.507 Max N = 200 avg. mfs: 905.185 DMD v0.157 dmd -O -inline -release Max N = 500 avg. mfs: 418.852 Max N = 200 avg. mfs: 485.995 Sun Java v1.5.0 java -server Max N = 500 avg. mfs: 596.748 Max N = 200 avg. mfs: 797.121 DMD closes the gap where N > 300 and cache size is the bottleneck. In general, DMD does very well at integer stuff and I'm assuming floating point has yet to be fully optimized. - Dave
May 17 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
What I'd do is do the most straightforward translation possible. Leave 
redesign for later. I've done this kind of thing before, and attempting 
to redesign during the translation makes it much, much more time 
consuming than doing it in two phases.
May 17 2006
prev sibling parent Bill Baxter <Bill_member pathlink.com> writes:
In article <e4cv4j$nqu$6 digitaldaemon.com>, Walter Bright says...
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?
BLAS? (Basic Linear Algebra Something-er-other) It's a set of very low-level routines for doing things like dot products and vector multiply-adds. LAPACK? Basic linear algebra functions like LU decompostion and the like. Lapack (and lots of other numerical libraries) rely on BLAS for low level array operations. The idea is that BLAS libraries can be highly tuned for particular architectures by particular vendors, taking into account things like cache sizes or special vector instructions. ATLAS is the canonical example of such a tuned BLAS library. Given an optimized BLAS library then your LAPACK or whatever should also run pretty fast without having to specifically tune it for each architecture individually. Not sure what porting either of those would showcase about D, though. Their interfaces are very basic, consisting of just a set of cryptically named functions to fit within ridiculous character limit of the original fortran compilers. It's about as far away as you can get from a modern, easy-to-use API. Porting (or reimplementing the concepts of) something like Blitz++ may be a better showcase for D. But I wouldn't know. I've never used Blitz++ despite the hype. It simply wouldn't compile with my compiler back when I was interested in trying it out. At any rate, any work on porting/writing a big numerical library should probably hold off until this new array stuff gets added to D. Regards, Bill Baxter
May 16 2006
prev sibling next sibling parent reply Bill Baxter <Bill_member pathlink.com> writes:
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: 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
May 16 2006
next sibling parent Brad Anderson <brad dsource.org> writes:
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
May 16 2006
prev sibling next sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
May 16 2006
prev sibling parent reply Ben Cooley <Ben_member pathlink.com> writes:
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; } }
May 16 2006
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 // 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++?
May 16 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4cvf6$pfi$1 digitaldaemon.com>, dennis luehring says...
 // 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)
What are you talking about? I have no intention of intantiating any templates at all. Templated classes are defered to the external cpp wrapper file: To make it a bit clearer.. templates are instantiated in this way in the wrapper Cpp code file. class __VectorInt : public std::vector<int> {}; D uses __VectorInt, which was the point of providing the cpptype {} keyword in the first place. The code within the braces is not parsed by D, but placed in an external cpp file which is compiled by a Cpp compiler into a standard Cpp class that D CAN use.
 // For instantiating constants
 cppconst int NULL { NULL };
This is to permit the assiging of Cpp macros to D constants. If the constants are simple, the value of the constant is directly assigned, if not, the constant expression is converted into an "extern int" reference, and the constant variable is placed in the Cpp file to be compiled by a Cpp compiler. // Cpp file definition for a complex macro constant int __COMPLEX_MACRO_CONSTANT = COMPLEX_MACRO_CONSTANT; Likewise, a complex functional macro can be placed in the Cpp file and wrapped with a standard c function: // In D if you the following... int i = cppmacro(int,int) MIN(100, 200); // Would cause a call to this function defined in the generated Cpp file below extern "C" { int __MIN(int a, int b) { return MIN(a,b); } }
 // 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)
I don't know.. is this a joke? Let me ask you, do you find yourself personally offended by these ideas?
 // 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)
Compared to what? A multi-year project to convert the C Windows API to D so that Windows software can finally be written? I would suggest if you don't like it, then don't feel that you have to use it.
ciao dennis

btw: how many years do you code c/c++?
21 years. I've actually used to own a copy of Zortech. How about you?
May 16 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e4dprq$4ga$1 digitaldaemon.com...
 Compared to what?  A multi-year project to convert the C Windows API to D 
 so
 that Windows software can finally be written?
Well, that's a pretty poor comparison, but the reason the Windows API (that is, just the header files) have taken so long is dues to copyright issues. We're not technically allowed to programmatically convert the official Windows headers over; that's been done, and it was done _ages_ ago. But it's not legal. So, instead, it has to be done the way it's being done, and as such, it's taken a while. Or rather, it hasn't taken that long, considering it started just a month or two ago. People have been writing Windows programs in D for a long time now. I mean, there's even a section about it in the spec. It's not like we've been diddling around on the console all this time.
May 16 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4dq4u$4ub$1 digitaldaemon.com>, Jarrett Billingsley says...
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e4dprq$4ga$1 digitaldaemon.com...
 Compared to what?  A multi-year project to convert the C Windows API to D 
 so
 that Windows software can finally be written?
Well, that's a pretty poor comparison, but the reason the Windows API (that is, just the header files) have taken so long is dues to copyright issues. We're not technically allowed to programmatically convert the official Windows headers over; that's been done, and it was done _ages_ ago. But it's not legal. So, instead, it has to be done the way it's being done, and as such, it's taken a while. Or rather, it hasn't taken that long, considering it started just a month or two ago. People have been writing Windows programs in D for a long time now. I mean, there's even a section about it in the spec. It's not like we've been diddling around on the console all this time.
Right. My mistake then. I knew that you could link with Windows libs, but I didn't know that you could actually code to a reasonably current version of the Windows API.
May 16 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e4dv0t$e18$1 digitaldaemon.com...

 Right.  My mistake then.

 I knew that you could link with Windows libs, but I didn't know that you 
 could
 actually code to a reasonably current version of the Windows API.
And hey, if none of the existing Windows headers have a really new API function, you can always look it up on MSDN, and put in the external declaration yourself, like extern(Windows) void SomeNewAPIFunc(char* lpszoifoiweoriworijName); (I hate Hungarian notation) Or, if the linker won't accept that, you can always.. _persuade_ it.
May 16 2006
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 D uses __VectorInt, which was the point of providing the cpptype {} keyword in
 the first place.  The code within the braces is not parsed by D, but placed in
 an external cpp file which is compiled by a Cpp compiler into a standard Cpp
 class that D CAN use.
due to the missing standart abi in c++ (there is no official and STABLE convention) - what is a "standart" cpp class that D CAN use? and even if we can make one cpp class a "standart" how do we link to your current object code... (does there the magic thing happen) if I don't get the point - can someone send me the c++ abi for some vc++ versions (5-2005) and borland/bcb c++ (3-2006)... because im involved in an projects which uses vc5, vc2005 and bcb4 it would be nice to link them together without preparing them (using dlls, COM interface,...)
 Likewise, a complex functional macro can be placed in the Cpp file and wrapped
 with a standard c function:
how to detect functional macros?, what means complex to you? can you help me convert this macro into an function #define DEFINT(varname,value)\
 I don't know.. is this a joke?  Let me ask you, do you find yourself personally
 offended by these ideas?
not offended but amused about your ideas (your first posts sounded like 21years of c/c++, your last posts becoming more and more 2.1 years of c/c++ or vb style...)
 Compared to what?  A multi-year project to convert the C Windows API to D so
 that Windows software can finally be written?
compared to what - a multi-year c++-to-D interface wrapper/compiler which wont ever become stable (because there is no stable abi) in the pure source code world c++ is nice and nearly vendor unspezific but c++ object code comes out of the hell... btw: the winapi project is just a (yes manualy made) conversion of the headers - because D can directly link c object code but yours is header conversion AND the linkage problem - the winapi port will be finished long, long time before
 I would suggest if you don't like it, then don't feel that you have to use it.
the problem is i would give it a try, but i don't think it would ever happen to exist...
 21 years.  I've actually used to own a copy of Zortech.  
ok then your familar with assembler (me too) can you please write a small class (template), compile your code with vc,gcc,bcb,bc (at least 2-3 different compilers) and then try to use it in assembler (maybe all objectcodes together) or try to find some good how-to-link-manuals * Name mangling In C++, names are mangled to encode the type of the symbol and allow overloading. So it may be called `MerryCallMe__voidfn__void' or something equally cryptic. You may have to look at the assembly to find out what it is. (vendor specific) * Calling conventions Member functions are often passed an invisible argument, which is (I think) their `this'. I think it's the first argument under GCC, but may be wrong. You'll have to pass it appropriately. (vendor specific)
 How about you?
just 17 years
May 16 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4eenc$18j6$1 digitaldaemon.com>, dennis luehring says...
 D uses __VectorInt, which was the point of providing the cpptype {} keyword in
 the first place.  The code within the braces is not parsed by D, but placed in
 an external cpp file which is compiled by a Cpp compiler into a standard Cpp
 class that D CAN use.
due to the missing standart abi in c++ (there is no official and STABLE convention) - what is a "standart" cpp class that D CAN use? and even if we can make one cpp class a "standart" how do we link to your current object code... (does there the magic thing happen) if I don't get the point - can someone send me the c++ abi for some vc++ versions (5-2005) and borland/bcb c++ (3-2006)... because im involved in an projects which uses vc5, vc2005 and bcb4 it would be nice to link them together without preparing them (using dlls, COM interface,...)
The format for OBJ files (OMF I believe) is on microsoft's msdn site. I don't know how current it is. However, I'm talking only about gcc's object file format.
 Likewise, a complex functional macro can be placed in the Cpp file and wrapped
 with a standard c function:
how to detect functional macros?, what means complex to you? can you help me convert this macro into an function #define DEFINT(varname,value)\
cppdecl { DEFINT(MyVar, 100) } int MyVar; Basically, as long as you know what the C linkage of a particular construct will be, you can simply push it over into the generated cpp file for a standard Cpp compiler (i.e. GCC) to figure out. In this case you would have the following code added to your generated file: extern "C" { DEFINT(MyVar,100) } ..and an implicit.. extern (C) int MyVar; . as if you manually wrote that code yourself. Taking snippets of Cpp code and placing them over in the generated Cpp file, and adding the proper D C extern linkages is not particularly difficult.
 I don't know.. is this a joke?  Let me ask you, do you find yourself personally
 offended by these ideas?
not offended but amused about your ideas (your first posts sounded like 21years of c/c++, your last posts becoming more and more 2.1 years of c/c++ or vb style...)
Hmmmm...
 Compared to what?  A multi-year project to convert the C Windows API to D so
 that Windows software can finally be written?
compared to what - a multi-year c++-to-D interface wrapper/compiler which wont ever become stable (because there is no stable abi)
GDC and GCC are tightly linked. When the abi of one changes, so does the other, likewise with GCC-XML. Any CPP which can be parsed by GCC can be output to GCC-XML. As far as the Windows C++ abi, it hasn't changed in years as far as I know. My MSVC 6 code still works with MSVC 8. There have been changes to the heap allocator, but not the way vtables are implemented or registers are used. But since the D windows compiler isn't open source anyway.. it doesn't matter? You'd either use an OMF compatible version of GCC/GCD, or recompile your windows code with MinGW, or not use D at all.
in the pure source code world c++ is nice and nearly vendor unspezific
but c++ object code comes out of the hell...

btw: the winapi project is just a (yes manualy made) conversion of the 
headers - because D can directly link c object code

but yours is header conversion AND the linkage problem - the winapi port 
will be finished long, long time before
Wanna bet? In any case, I only have to finish my system once and I'm finished. You're never going to be finished porting the Windows API headers.
 I would suggest if you don't like it, then don't feel that you have to use it.
the problem is i would give it a try, but i don't think it would ever happen to exist...
Of course not. It is, after all, impossible as many people have explained to me in vauge detail. Why would somebody ever even consider such a crazy idea, and who would want it anyway.
 21 years.  I've actually used to own a copy of Zortech.  
ok then your familar with assembler (me too) can you please write a small class (template), compile your code with vc,gcc,bcb,bc (at least 2-3 different compilers) and then try to use it in assembler (maybe all objectcodes together) or try to find some good how-to-link-manuals
Uh.. why would I want to do that?
* Name mangling
In C++, names are mangled to encode the type of the symbol and allow
overloading.  So it may be called `MerryCallMe__voidfn__void' or
something equally cryptic.  You may have to look at the assembly to find
out what it is.
(vendor specific)
I'm only interested in GCC. Those other vendors can fend for themselves.
* Calling conventions
Member functions are often passed an invisible argument, which is (I
think) their `this'.  I think it's the first argument under GCC, but may
be wrong.  You'll have to pass it appropriately.
(vendor specific)

 How about you?
just 17 years
Sure, Cpp calls also often pass silent return argument parameters in some cases. There are a number of details to consider.. but it's certainly not impossible, or improbably difficult as some of the people here would have you believe.
May 17 2006
parent reply dennis luehring <dl.soluz gmx.net> writes:
 The format for OBJ files (OMF I believe) is on microsoft's msdn site. I don't
 know how current it is. 
the obj file format is just one part of the way - i don't found any vc related abi descriptions? have microsoft ever released an offical c++ abi description?
 However, I'm talking only about gcc's object file
 format.
g++ has the most unstable c++ abi in the hole c++ compiler world the gcc c++ abi changes from version to version - i think ~100 times :-) since 2.9xxx the abi for the 4.x seem to become a "little bit" more stable
 GDC and GCC are tightly linked.  When the abi of one changes, so does the
other,
 likewise with GCC-XML.  Any CPP which can be parsed by GCC can be output to
 GCC-XML.
so you saiy walter should "follow" this permanent abi changes? for at least 3 compiler-vendors (micorsoft, borland(which i need), gcc) with the chances of never getting to the point of having an full-out-of-the-box-working version? what do you think will other no so gentle developers like us will say if D do it this way? you can use c-style D in C (bidirectional) why do think is there no c++ compiler out there whos speaking other c++ abi's then its own?
 As far as the Windows C++ abi, it hasn't changed in years as far as I know.  My
 MSVC 6 code still works with MSVC 8.  There have been changes to the heap
 allocator, but not the way vtables are implemented or registers are used.  
the vc6 object code isn't realy compatible with vc8 version (on what level?) the microsofts c++ abi changed another time... (where are the documents? can anyone help with an link?)
 But since the D windows compiler isn't open source anyway.. it doesn't matter?
 You'd either use an OMF compatible version of GCC/GCD, or recompile your
windows
 code with MinGW, or not use D at all.
i will never start to use another compiler in parts(or hole) of some of my years living projects - they are stable under development and i don't have the time and "power" to try out how far such a D feature is capable of link with my code wihtout any error (im afraid of hidden errors - found then months later...) will you port parts of your project over if needed to mingw or something else only to get in contact with D? in my company the vc and bc compiler is in use for years - because they are stable and under heavy use by mio. other developers - im not allowed to change the compilerbase!
 but yours is header conversion AND the linkage problem - the winapi port 
 will be finished long, long time before
Wanna bet? In any case, I only have to finish my system once and I'm finished. You're never going to be finished porting the Windows API headers.
why don't have you posted such message into the mingw forum years ago :-)
 I would suggest if you don't like it, then don't feel that you have to use it.
the problem is i would give it a try, but i don't think it would ever happen to exist...
Of course not. It is, after all, impossible as many people have explained to me in vauge detail. Why would somebody ever even consider such a crazy idea, and who would want it anyway.
i want it
 Uh.. why would I want to do that?
just to get near to the problems with the linking
 Sure, Cpp calls also often pass silent return argument parameters in some
cases.
 There are a number of details to consider.. but it's certainly not impossible,
 or improbably difficult as some of the people here would have you believe.
your right - its not impossible - but why should walter try to implement such an linkable feature into D with no stable abis around while he's building an next genration language? i need a description of current c++ abi of vc(6,7,8), bc(5.x,...) and gcc(3.2 to 4.x) cioa dennis
May 17 2006
parent reply Brad Roberts <braddr puremagic.com> writes:
On Wed, 17 May 2006, dennis luehring wrote:

 The format for OBJ files (OMF I believe) is on microsoft's msdn site. I
 don't
 know how current it is. 
the obj file format is just one part of the way - i don't found any vc related abi descriptions? have microsoft ever released an offical c++ abi description?
 However, I'm talking only about gcc's object file
 format.
g++ has the most unstable c++ abi in the hole c++ compiler world the gcc c++ abi changes from version to version - i think ~100 times :-) since 2.9xxx the abi for the 4.x seem to become a "little bit" more stable
Since gcc 3.0 that's not been true. The abi adopted with gcc 3.0 and beyond is based on a spec that's been agreed upon by all the major unix compiler vendors. There's been a few fixes primarily in 3.2 and 3.3 (if I remember right) to fix some corner cases. Since 3.4 there haven't been any major abi changes that I can recall. The same can be said of the hp, sun, ibm, etc compilers.. their first releases of the new abi weren't perfect either. For the last several years, each has been stable and compatible. The only major vendor today that _doesn't_ support this abi is microsoft (and borland if you want to count them). Later, Brad
May 17 2006
parent reply dennis luehring <dl.soluz gmx.net> writes:
Brad Roberts schrieb:
 On Wed, 17 May 2006, dennis luehring wrote:
 However, I'm talking only about gcc's object file
 format.
g++ has the most unstable c++ abi in the hole c++ compiler world the gcc c++ abi changes from version to version - i think ~100 times :-) since 2.9xxx the abi for the 4.x seem to become a "little bit" more stable
Since gcc 3.0 that's not been true. The abi adopted with gcc 3.0 and beyond is based on a spec that's been agreed upon by all the major unix compiler vendors. There's been a few fixes primarily in 3.2 and 3.3 (if I remember right) to fix some corner cases. Since 3.4 there haven't been any major abi changes that I can recall. The same can be said of the hp, sun, ibm, etc compilers.. their first releases of the new abi weren't perfect either. For the last several years, each has been stable and compatible.
ok, ok ("~100 times" was a joke) but there are enough small changes in the last years to call the (*nix) c++ abi still unstable - do you think the abi is nowerdays stable enough to become integrated into the D linker?
 The only major vendor today that _doesn't_ support this abi is microsoft 
 (and borland if you want to count them).
a D features to link c++ code without these two major vendors makes absolutly no sens (to me) - where can i find docs about there abis ciao dennis
May 17 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e4gvun$hg2$1 digitaldaemon.com>, dennis luehring says...
Brad Roberts schrieb:
 On Wed, 17 May 2006, dennis luehring wrote:
 However, I'm talking only about gcc's object file
 format.
g++ has the most unstable c++ abi in the hole c++ compiler world the gcc c++ abi changes from version to version - i think ~100 times :-) since 2.9xxx the abi for the 4.x seem to become a "little bit" more stable
Since gcc 3.0 that's not been true. The abi adopted with gcc 3.0 and beyond is based on a spec that's been agreed upon by all the major unix compiler vendors. There's been a few fixes primarily in 3.2 and 3.3 (if I remember right) to fix some corner cases. Since 3.4 there haven't been any major abi changes that I can recall. The same can be said of the hp, sun, ibm, etc compilers.. their first releases of the new abi weren't perfect either. For the last several years, each has been stable and compatible.
ok, ok ("~100 times" was a joke) but there are enough small changes in the last years to call the (*nix) c++ abi still unstable - do you think the abi is nowerdays stable enough to become integrated into the D linker?
 The only major vendor today that _doesn't_ support this abi is microsoft 
 (and borland if you want to count them).
a D features to link c++ code without these two major vendors makes absolutly no sens (to me) - where can i find docs about there abis
Interesting that you would say that. Not being able to use any existing C or Cpp at all makes even less sense to me. The point is that I can write software in D on any platform supported by GDC and use any C or Cpp library that can be compiled by GCC on Windows, Linux, or OSX. How many usage scenarios do you think that would cover? As far as the original D compiler Walter wrote.. it won't be compatible with projects written for GDC code which used Cpp interop.
May 18 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e4it0v$3p9$1 digitaldaemon.com...

 Not being able to use any existing C or
 Cpp at all makes even less sense to me.
YOU! CAN! LINK! TO! C! CODE! NATIVELY! IN! D! Did you miss that somewhere?
May 18 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Jarrett Billingsley wrote:
 "Ben Cooley" <Ben_member pathlink.com> wrote in message 
 news:e4it0v$3p9$1 digitaldaemon.com...
 
 Not being able to use any existing C or
 Cpp at all makes even less sense to me.
YOU! CAN! LINK! TO! C! CODE! NATIVELY! IN! D! Did you miss that somewhere?
Seriously, this has been pounded back at you (Ben) for many posts. Listen to what we are saying. -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
May 18 2006
parent Bill Baxter <Bill_member pathlink.com> writes:
In article <e4ji0l$hcl$1 digitaldaemon.com>, Kyle Furlong says...
Jarrett Billingsley wrote:
 "Ben Cooley" <Ben_member pathlink.com> wrote in message 
 news:e4it0v$3p9$1 digitaldaemon.com...
 
 Not being able to use any existing C or
 Cpp at all makes even less sense to me.
YOU! CAN! LINK! ... Did you miss that somewhere?
Seriously, this has been pounded back at you (Ben) for many posts. Listen to what we are saying.
I think Ben gets that point just fine. Yes, you can link with C. *But* you need to rewrite the header in D first. Which isn't quite the same as being able to "use existing C". Granted the manual labor to use C from D is less than for using it from Java or Python, but still, there's some manual labor involved. Anyway, if you've been reading his posts closely I think it's pretty clear that he's primarily concerned with C++, anyway, and not so much C. But if his grand plan for C++ via GCC-XML works out, then C will be taken care of too as a by-product. Anyway, there's no reason to jump all over the guy for wanting to make D interoperate better with C and C++. My impression, though, is that what Ben wants to do is still pretty similar to what SWIG already does. It's generating wrappers. In SWIG's case it generates say a Python API plus some supporting Python and C++ glue code. In Ben's case he's talking about generating a D API with D and C++ glue code (and maybe a little assembly thrown in to manipulate vtables and such), but they're wrappers nonetheless. So to me it makes most sense to either A) leverage SWIG and add the necessary functionality it or B) start over from scratch with a completely new wrapper generator tool based on GCC-XML. But if you're going spend all that time making a new wrapper generator that's better than SWIG, why limit it to only wrapping D? If you By the way a search for "GCCXML wrapper generator" turns up this as the first link: http://www.digitalmars.com/d/archives/digitalmars/D/announce/113.html The site for that is here: http://remy.moueza.free.fr/ Sounds like it was abandoned, but at he's got some experience on the problem, and is likely to know where the really tricky parts are. Cheers! Bill Baxter
May 19 2006
prev sibling parent reply Bill Baxter <Bill_member pathlink.com> writes:
In article <e4cubh$nou$1 digitaldaemon.com>, Ben Cooley says...
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.
Yes, we're in agreement insofar as we both think it would be good if it were easier to use legacy C and C++ code with new D code. I think the majority of readers of this list would agree there's nothing wrong with that. They might prioritize it differently, but I think most everyone here can agree that if a magic wand could make C++ callable from D then it should be done. But seeing Walter's Giant List of all the interoperability issues pretty much clenches it for me that making D work _directly_ with C/C++ is just a non-starter. Not unless Google "buys" D tomorrow and throws 20 full time engineers on it. On the other hand, SWIG, or SWIG-like, wrapping of C/C++ for consumption by D is a much more feasible, realistic goal. SWIG makes the easy stuff easy (automatic, just %include "header.h") and the hard stuff doable (with manual annotations), but it doesn't magically make the impossible possible (like porting the STL to Python). Forgive me if I'm misunderstanding you, but your talk of accessing vtables and such from D sounds like you're still thinking of making D understand C++ binaries. I just don't think that's practical given the current D development situation. But I think it would only take one or two determined souls to revive the SWIG approach and wrangle it into something useful. Speaking of Google, and projects for one or two determined souls, were there any D proposals submitted to the Google Summer of Code? Regards, Bill Baxter
May 16 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
Yes, we're in agreement insofar as we both think it would be good if it were
easier to use legacy C and C++ code with new D code.  I think the majority of
readers of this list would agree there's nothing wrong with that.  They might
prioritize it differently, but I think most everyone here can agree that if a
magic wand could make C++ callable from D then it should be done.  But seeing
Walter's Giant List of all the interoperability issues pretty much clenches it
for me that making D work _directly_ with C/C++ is just a non-starter.  Not
unless Google "buys" D tomorrow and throws 20 full time engineers on it.  On the
other hand, SWIG, or SWIG-like, wrapping of C/C++ for consumption by D is a much
more feasible, realistic goal.  SWIG makes the easy stuff easy (automatic, just
%include "header.h") and the hard stuff doable (with manual annotations), but it
doesn't magically make the impossible possible (like porting the STL to Python).

Forgive me if I'm misunderstanding you, but your talk of accessing vtables and
such from D sounds like you're still thinking of making D understand C++
binaries.  I just don't think that's practical given the current D development
situation.  But I think it would only take one or two determined souls to revive
the SWIG approach and wrangle it into something useful.
The majority of issues Walter listed simply don't apply to the strategy I'm going to try. There are no issues with parsing because that task is handled using an external tool (GCC-XML). There are no issues with specific C++ language details because any construct outside of cpp vtable calls or member access are simply punted to wrappers in the auto generated Cpp file. As for swig, the parsing of headers in SWIG is not really adequate IMO. It takes shortcuts which tend to break. In any case, since GCC-XML exists, and it was actually written specifically to produce the precise sort of reflection info you need here, why bother with an imprecise parser like swig? They're using GCC-XML for the current C++ reflection library at cern and I've personally parsed some of our own code here, and it works fine. Of course Elsa also works on our code here after running it through the pre-processor.. which is quite remarkable given the extensive amount of template programming we use, but it doesn't parse some of the MS specific stuff which GCC-XML handles. In any case, I really think you can do better than wrapping. If you can get an accurate vtable layout, macros, method list and params, and class/struct layout for standard classes, you pretty much have the information that you need to access members and call vtable methods. For the rest: templates, complex macros, exception handling, rtti, etc.. yes, I'm saying it would use inline cpp {} and generate "wrapper code" for these the same way swig does.. and call this wrapper code via extern C function calls to an externally compiled and linked Cpp file.
May 16 2006
parent Bill Baxter <Bill_member pathlink.com> writes:
In article <e4e0v2$i78$1 digitaldaemon.com>, Ben Cooley says...
The majority of issues Walter listed simply don't apply to the strategy I'm
going to try.  
That's truly excellent if you're really going to give this a shot. I wish you luck.
 There are no issues with parsing because that task is handled
using an external tool (GCC-XML).  There are no issues with specific C++
language details because any construct outside of cpp vtable calls or member
access are simply punted to wrappers in the auto generated Cpp file.

As for swig, the parsing of headers in SWIG is not really adequate IMO.  It
takes shortcuts which tend to break.  In any case, since GCC-XML exists, and it
was actually written specifically to produce the precise sort of reflection info
you need here, why bother with an imprecise parser like swig?  They're using
GCC-XML for the current C++ reflection library at cern and I've personally
parsed some of our own code here, and it works fine.  Of course Elsa also works
on our code here after running it through the pre-processor.. which is quite
remarkable given the extensive amount of template programming we use, but it
doesn't parse some of the MS specific stuff which GCC-XML handles.
Fair enough. That sounds like an argument against using SWIG for any purpose, not just against using it to wrap D. Maybe you'll create the startings of XNSWIG ("XNSWIG's Not SWIG"), a new SWIG replacement based on GCC-XML. :-)
In any case, I really think you can do better than wrapping. If you can get an
accurate vtable layout, macros, method list and params, and class/struct layout
for standard classes, you pretty much have the information that you need to
access members and call vtable methods.

For the rest: templates, complex macros, exception handling, rtti, etc.. yes,
I'm saying it would use inline cpp {} and generate "wrapper code" for these the
same way swig does.. and call this wrapper code via extern C function calls to
an externally compiled and linked Cpp file.  
If you really think you can make it happen then by all means jump to it. If it works, many folks will sing your praises. Regards, Bill Baxter
May 16 2006
prev sibling next sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
May 16 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
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.
May 16 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
May 16 2006
parent reply Paulo Herrera <pauloh81 yahoo.ca> writes:
Walter Bright wrote:
 
 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.
Walter, I guess you have good reasons to think in this way, but my experience is different. I've been in two different graduate schools and at two different departments (Civil Engineering and Earth Sciences). I think the situation in those departments in different to what people observe in a CS department. In both places I met people that buy expensive Fortran compilers not only to compile old libraries, but to write new code. I know people that write large parallel codes in Fortran and that use a C library (PETSc) for the core numerical routines. Most of them are young researchers, so they learned Fortran few years ago. So, I don't think Fortran is still around because of old legacy code or "old legacy programmers". I think most of that people use Fortran because there wasn't anything better for that kind of code. I think/hope D can be a viable alternative. Paulo.
May 16 2006
parent reply Bill Baxter <Bill_member pathlink.com> writes:
In article <e4dhnf$1l5n$1 digitaldaemon.com>, Paulo Herrera says...
Walter Bright wrote:
 
 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.
Walter, I guess you have good reasons to think in this way, but my experience is different. I've been in two different graduate schools and at two different departments (Civil Engineering and Earth Sciences). I think the situation in those departments in different to what people observe in a CS department. In both places I met people that buy expensive Fortran compilers not only to compile old libraries, but to write new code. I know people that write large parallel codes in Fortran and that use a C library (PETSc) for the core numerical routines. Most of them are young researchers, so they learned Fortran few years ago. So, I don't think Fortran is still around because of old legacy code or "old legacy programmers". I think most of that people use Fortran because there wasn't anything better for that kind of code. I think/hope D can be a viable alternative.
Yeh, my impression is that Fortran users care most about A) the ability to easily use the gobs of existing Fortran code thats out there and B) having basic operations like C[i] = A[i] + B[i] run as fast as possible for their given architecture. I seem to recall Fortran also has some other syntactic sugar that makes various array operations easier than with C. Not sure how important that is. For A) nothing beats the ease of calling legacy fortran code than fortran itself. It's hard to beat there. For B) C's lack of alias-free arrays means C compilers can't optimize as aggressively as Fortran ones. C99 has the restrict keyword, but here it is seven years after the C99 standard, and the big compiler vendors still don't seem interested in implementing it. And besides if you're using Fortran, you're doing numerics. Fast numerical code is pretty much the only benchmark that matters in that world, so if you want to sell a fortran compiler, it better do a great job on numerical code. C compiler writers sell to a much wider variety of folks, so the need to optimize numerics in order to make a profit is much less. None of the above has anything to do with whether Fortran is a great language or not. Its good enough to get their job done, and the costs of moving to a different language outweigh the benefits for some folks. And even if young researchers are using it, I suspect that that also has a lot more do with what their professors were proficient with than the merits of the language -- i.e. it *is* a legacy/inertia issue. I took a few classes in the Applied Math dept where the prof would provide a skeleton of Fortran code or some support code in fortran and you were supposed to fill in the rest. He said we were free to use C or C++, but then we'd have to scrap together our own bootstrap code. I went with C++ but every other student in the class went with Fortran, because it was the default path, and because the prof was more likely to be able to provide help with the Fortran. Er, so summing up, I'm agreeing with you Paolo, that some people aren't going to give up on Fortran just because a better language comes along. But mostly because of how easy it is to call Fortran from Fortran, and because that's what they teach to young numerical researchers. But that's not everyone. Some numerics people do see the light and long for better more scalable tools and aren't afraid to spend time learning something new. I know at least one dyed-in-the-wool fortran numerics guy who's writing a massive new library in C++ because he wants the modularity maintainability provided by OO abstractions. But currently he has to put up with people saying his code is going to be slower than the equivalent Fortran code. If D could match Fortran for raw numeric speed then at least that one argument would go away. So I agree with Walter that if D can be as good at numerics as Fortran then some, but certainly not all, new code would be written in D. This guy's library is a good example. Big new C++ code base with virtually no external dependencies. Probably would have been perfect for D if he had known about it -- and if D had been 1.0 when he started -- and if there had been sufficient resources (like books) out there to learn how to program in D. Bill Baxter
May 16 2006
parent reply John Reimer <terminal.node gmail.com> writes:
Bill Baxter wrote:
 In article <e4dhnf$1l5n$1 digitaldaemon.com>, Paulo Herrera says...
 Walter Bright wrote:
 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.
Walter, I guess you have good reasons to think in this way, but my experience is different. I've been in two different graduate schools and at two different departments (Civil Engineering and Earth Sciences). I think the situation in those departments in different to what people observe in a CS department. In both places I met people that buy expensive Fortran compilers not only to compile old libraries, but to write new code. I know people that write large parallel codes in Fortran and that use a C library (PETSc) for the core numerical routines. Most of them are young researchers, so they learned Fortran few years ago. So, I don't think Fortran is still around because of old legacy code or "old legacy programmers". I think most of that people use Fortran because there wasn't anything better for that kind of code. I think/hope D can be a viable alternative.
Yeh, my impression is that Fortran users care most about A) the ability to easily use the gobs of existing Fortran code thats out there and B) having basic operations like C[i] = A[i] + B[i] run as fast as possible for their given architecture. I seem to recall Fortran also has some other syntactic sugar that makes various array operations easier than with C. Not sure how important that is. For A) nothing beats the ease of calling legacy fortran code than fortran itself. It's hard to beat there. For B) C's lack of alias-free arrays means C compilers can't optimize as aggressively as Fortran ones. C99 has the restrict keyword, but here it is seven years after the C99 standard, and the big compiler vendors still don't seem interested in implementing it. And besides if you're using Fortran, you're doing numerics. Fast numerical code is pretty much the only benchmark that matters in that world, so if you want to sell a fortran compiler, it better do a great job on numerical code. C compiler writers sell to a much wider variety of folks, so the need to optimize numerics in order to make a profit is much less. None of the above has anything to do with whether Fortran is a great language or not. Its good enough to get their job done, and the costs of moving to a different language outweigh the benefits for some folks. And even if young researchers are using it, I suspect that that also has a lot more do with what their professors were proficient with than the merits of the language -- i.e. it *is* a legacy/inertia issue. I took a few classes in the Applied Math dept where the prof would provide a skeleton of Fortran code or some support code in fortran and you were supposed to fill in the rest. He said we were free to use C or C++, but then we'd have to scrap together our own bootstrap code. I went with C++ but every other student in the class went with Fortran, because it was the default path, and because the prof was more likely to be able to provide help with the Fortran. Er, so summing up, I'm agreeing with you Paolo, that some people aren't going to give up on Fortran just because a better language comes along. But mostly because of how easy it is to call Fortran from Fortran, and because that's what they teach to young numerical researchers. But that's not everyone. Some numerics people do see the light and long for better more scalable tools and aren't afraid to spend time learning something new. I know at least one dyed-in-the-wool fortran numerics guy who's writing a massive new library in C++ because he wants the modularity maintainability provided by OO abstractions. But currently he has to put up with people saying his code is going to be slower than the equivalent Fortran code. If D could match Fortran for raw numeric speed then at least that one argument would go away. So I agree with Walter that if D can be as good at numerics as Fortran then some, but certainly not all, new code would be written in D. This guy's library is a good example. Big new C++ code base with virtually no external dependencies. Probably would have been perfect for D if he had known about it -- and if D had been 1.0 when he started -- and if there had been sufficient resources (like books) out there to learn how to program in D. Bill Baxter
Just curious: how does Fortran scale for use of parallel computations? Perhaps some Fortran compilers are more advanced in that field than C/C++? If so, lack of intrinsic (computational) parallel support (ie, easily programmable) could be a short-coming that D might continue to share with C/C++? Could this also be a reason Fortran still remains more attractive to some extent? Of course, I'm not familiar enough with scientific uses of Fortran to comment on that language comparatively. I just wonder if some of these advanced Fortran compilers also contain automatic parallelism of some of the computational tasks? On a slightly different but related topic: My observation of D is that, as wonderful a language as it is, it still inherits much of the same low-level concurrency difficulties of C/C++. There's no adoption of clean/provable parallel constructs as should be seen in languages hoping to take on the 21st century's multi-core systems. We're still stuck with the tricky/deadlock-friendly mechanisms of mutex's and semaphores that require highly skilled programming and extremely astute/alert developers (even then deadlocks are often unpredictable). We need something higher level (and provable) to lighten the load for D users and remove the nasty complexities from parallel programming. (see CSP -- Communicating Sequential Processes -- and Pi Calculus type constructs/constraints). Such high-level parallelism support is usually most palatable and useful by integrating the constructs with keywords within the language (I'm not sure how attractive these features would be if integrated via mixins or templates in D, but it has been done to some degree with object inheritance in other languages [see JCSP for Java]) A month or so ago, Kris first pointed this out in a previous post to this newsgroup. Granted, I think such a feature is a difficult task to integrate into D, but I also think it's one major detail that would really set D apart from other computer languages. The addition would likely be considered hugely welcome in multiple scientific, engineering, and computational science sub-cultures. -JJR
May 16 2006
parent Walter Bright <newshound digitalmars.com> writes:
John Reimer wrote:
 Just curious: how does Fortran scale for use of parallel computations? 
 Perhaps some Fortran compilers are more advanced in that field than 
 C/C++?  If so, lack of intrinsic (computational) parallel support (ie, 
 easily programmable) could be a short-coming that D might continue to 
 share with C/C++?  Could this also be a reason Fortran still remains 
 more attractive to some extent?
The C/C++ compiler vendors, to a large extent, just don't "get it" when it comes to numerics code. For evidence of that, you don't need to look further than dropping 80 bit floating point support. I just can't take seriously the numerics capability of a compiler that doesn't even support the basic FPU types that have been around for 20 years. For another, you should see some of the postings people have sent to me about how C++'s <complex> class is good enough.
May 16 2006
prev sibling parent Ben Cooley <Ben_member pathlink.com> writes:
In article <14fakmish13b0.1mid2engjqpes.dlg 40tude.net>, Derek Parnell says...
On Sun, 14 May 2006 23:22:56 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 But all joking aside, it just occurred to me that Digitalmars already has a
 tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm
 wondering if Walter could provide a new utility that can help us automate
 translation of C/C++ headers into D source code?
There's no way to do that with C++ - just take a look at any Boost headers :-). It is possible to do a 90% automatic translation of C headers.
May I repeat a portion of my post please ... "a new utility that can **help** us automate translation of C/C++ headers into D source code" I know that 100% automated translation is not practical. However, as DigitalMars already has a C/C++ parser that works, I was thinking that a tool based on that parser to created a best-effort translation and highlighted that which needs human effort might be a useful addition to the D tool set. Whatever you have now as a C/C++ parser has got to be better than writing a new one from scratch. I'm not asking for the source code for that parser, just a tool that would output something that could be tweaked into D code by either (or both) another tool or person.
Well, what you have is both several full C/C++ parsers and full compilers out there (for example the Digital Mars Compiler or GCC), AND full control of the D language specification. The incompatibility with C plus plus is a current design decision. It really doesn't matter in the grand scheme of things.. C plus plus will be the language of choice simply because it integrates and can use exiting code, and is good enough at everything else. D will continue neither being able to parse C and C++ header files or integrate with C++, and remain not widely used.
May 15 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
I only agree with 2 points: the lack of a rich library, and the lack (so 
far) of an IDE, but the lattar is not part of the language per se.

Guess what, I came to D because I hated C++.
C++ has the worst set of libraries ever. If you compare what C++ has vs. 
what Java has, the Java libraries would win anyday!
Even if the same library was written for both Java and C++, the Java 
version would always win. (look at the ICU library for example).


wasn't a show stopper for them.

can also be a recruitment tool for D.

The solution is to create a library similar to the Java api or the .NET 
framework.
This solution has not yet been realized, but there is some promice in 
dsource.org, specially the Mango project.


As for the IDE, well, there's "Posiedon". It's not perfect, but I think 
it's just fine. I always use it, and it's a big time saver.


Ben Cooley wrote:
 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/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

 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

 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.
 
 
 
 
 
 
 
 
 
 
 
 
May 14 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
In article <e494td$jvc$1 digitaldaemon.com>, Hasan Aljudy says...
I only agree with 2 points: the lack of a rich library, and the lack (so 
far) of an IDE, but the lattar is not part of the language per se.

Guess what, I came to D because I hated C++.
C++ has the worst set of libraries ever. If you compare what C++ has vs. 
what Java has, the Java libraries would win anyday!
Even if the same library was written for both Java and C++, the Java 
version would always win. (look at the ICU library for example).
I don't disagree. However it's simply not possible to do any sort of practical programming without using these libraries, and it's extremely tedious to have to wrap each library. C plus plus is not as clean or as nice to program in as D, but at least I don't have to wrap all of the external code that I need to use.. and the code I write will also be useful to other C/C++ programmers. That's what you're up against here. disadvantages of not having direct and immediate access to system level libraries written in C and C++. Yet D is intended as a system level programming languages. The fact that it can't understand the entire body of system level code in C and C plus plus, and it doesn't play nice with C plus plus is a serious.. probably fatal.. drawback. It really doesn't have to be that way though.

wasn't a show stopper for them.

can also be a recruitment tool for D.
number of reasons.
May 15 2006
next sibling parent Dave <Dave_member pathlink.com> writes:
Ben Cooley wrote:
 In article <e494td$jvc$1 digitaldaemon.com>, Hasan Aljudy says...
 I only agree with 2 points: the lack of a rich library, and the lack (so 
 far) of an IDE, but the lattar is not part of the language per se.

 Guess what, I came to D because I hated C++.
 C++ has the worst set of libraries ever. If you compare what C++ has vs. 
 what Java has, the Java libraries would win anyday!
 Even if the same library was written for both Java and C++, the Java 
 version would always win. (look at the ICU library for example).
I don't disagree. However it's simply not possible to do any sort of practical programming without using these libraries, and it's extremely tedious to have to
I strongly disagree; at least in the environments that I've been working in over the past 5 years using C and C++, I could have done a lot of the work with D and phobos as-is. What I've been doing in those languages is a lot of small "script-like" utilities that need high-performance, and a couple of larger server-side projects that use parts of the STL (that can be replaced for the most part with D built-ins like first class arrays, char[] instead of std::string and AA's). The other DB and web-related stuff I've been doing, I wouldn't use C or C++ for anyhow. D won't take over the world in 'one fell swoop', it's primary initial use will be things like the above, and it will be new development and not porting of C or C++ code that's already been debugged and in operation. That said, Walter has taken his ECMAScript implementation and ported that from C++ to D. It was done with about 1/2 the source code (including non-std libs) and runs about 25% faster. What Walter describes here coincides with what I claim above (built-ins obviate the need for a lot of C++ library functionality): http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28938 Your OP sounds a lot like what I would have said a year and a half ago before I started to experiment w/ D in earnest. Now, I see little utility in complex "D to X" conversion projects. A conversion utility for the most widely used C++ libs. (template based) isn't practical, and headers converted using a C to D conversion program would probably require as much time to verify as just doing by hand and verifying as you go. Besides, with a conversion tool, an opportunity to "refactor" old C headers and libs. is lost. About the only thing I agree with the OP about is that the library is a bit sparse. I agree that some more could be added to the std. lib. and at the very least the std.c.linux.* (DMD) vs. std.c.unix.* (GDC) issue needs to be resolved quickly for portability between the compilers. And what I see as the most important missing parts of the std. lib. have been addressed with mango (IO) and DWT (GUI) once DWT is available for Linux. Oh, and probably XML support needs to be added, and there are projects addressing that as well. I see in another post that your OP was predicated on your experience with a specific large C++ project in mind. You need to include details like that before you post "show stopper" issues for D... In your current world they may be show stoppers, but for most of the rest, what you list as a show-stopper really isn't.
 wrap each library.  C plus plus is not as clean or as nice to program in as D,
 but at least I don't have to wrap all of the external code that I need to use..
 and the code I write will also be useful to other C/C++ programmers.  That's
 what you're up against here.
 

 disadvantages of not having direct and immediate access to system level
 libraries written in C and C++.  Yet D is intended as a system level
programming
 languages.  The fact that it can't understand the entire body of system level
 code in C and C plus plus, and it doesn't play nice with C plus plus is a
 serious.. probably fatal.. drawback.  It really doesn't have to be that way
 though.
 

 wasn't a show stopper for them.

 can also be a recruitment tool for D.
number of reasons.
May 15 2006
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e4a3rm$25v9$1 digitaldaemon.com...

 of the
 disadvantages of not having direct and immediate access to system level
 libraries written in C and C++.  Yet D is intended as a system level 
 programming
 languages.  The fact that it can't understand the entire body of system 
 level
 code in C and C plus plus, and it doesn't play nice with C plus plus is a
 serious.. probably fatal.. drawback.
Most truly system-level code is written in C, with which D can already interface on a binary level. So why bother making D compile C, when there are tons of C compilers out there already, and if D can already link with C code? As for C++, name _one other language besides C++_ that can natively link with C++. IT CANNOT BE DONE, for the reasons already explained: there is no unified C++ ABI, and as such, C++ libraries generated by different C++ compilers are often binary-incompatible. Making D binary compatible with C++ would mean nothing; it'd be binary compatible with one small segment of C++ code and nothing else.

 for a
 number of reasons.
multinational companies backing their development, then yes, I agree that they can't be compared with D in terms of the "star power" that they have been given by their deep-pocketed creators. However, in terms of simplicity, orthogonality, and expressiveness, D just seems like a
May 15 2006
prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
First of all Ben:

Welcome to the D community!

I would like to apologize for the less than optimal welcome you have 
received so far; they should know better. That being said, I do agree 
with them on a few points, specifically the comments regarding C++/C 
compatibility. The rest of my comments are embedded.

Ben Cooley wrote:
 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.
 
http://www.digitalmars.com/d/htomodule.html is a helpful guide. However, its not an automated tool. Also, http://www.digitalmars.com/d/pretod.html is a good read. An automated tool would be a very complex piece of software, and there have been multiple attempts by various members of the community. The fact remains that hand translation is faster than writing an automated translator.
 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. 
 
The idea here is that C++ library code can be wrapped in a C interface. In that way, D and C++ can communicate. One does not need to recode the entire C++ library code base, and C libraries are a short days work of translating headers away. Have you tried to do this? It really doesnt take as long as I believe you are imagining. For example, I got a workable Cairo module translated in about two hours. As regards COM: http://www.digitalmars.com/d/dll.html#com In fact, D treats COM objects specially within the runtime/compiler. Its kinda magical, and maybe others who know better can inform you more completely.
 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.
 
See previous comment. D -> C -> C++ -> C -> D
 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.
 
Examples of things you have had trouble porting? We can help.
 Provides no additional support for safe programming vs. C/C++  Importance: HIGH
 ---------------------------------------------
 

 C/C++ for the additional productivity and security.  D trades incompatibility
 for.. incompatibility.  Programming in D is just as unsafe as programming in C
I'm sorry, did I miss an explanation? What incompatibility are you speaking of?
 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

 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?
 
D is a practical language. Because of this, the user is offered easy access to low level features like pointers and inline assembly. However, if you look at most D library code, which by the way mostly resides at www.dsource.org, you will find that these features are rarely used. The idea is that the compiler will not decide for you how you want to program. If you want to code in a procedural manner, you are welcome to do so. If you would like to write in a very high level manner with Objects, Interfaces, Mixins, and Templating, you are also welcome to do so. With any style you choose you may also choose to subvert the type system, GC, and other language features by using pointers and/or assembly. Whatever style you prefer, and even if you use the low level features, D offers two things which C/C++ doesn't. Unittesting and design by contract. These two tools, which are build into the spec and both compilers, enable one to safely write any code you like.* For more information on these two features: http://www.digitalmars.com/d/dbc.html http://www.digitalmars.com/d/cppdbc.html http://www.digitalmars.com/d/class.html#unittest I cant find the page for unit tests in general, but the syntax is valid at the module level as well. For example: module bar; int one() { return 1; } unittest { assert(one() == 1); } float square(float x) { return x*x; } unittest { assert(square(2) == 4); } These are run in the order they appear lexically. Unit tests are turned on by sending the compiler the -unittest switch. * Obviously if you choose to write code with pointers and assembly that is intentionally unsafe, you are doing so at your own risk. My point is that that is your choice. Its like we used to say in volleyball, the ball only goes where you tell it to, so its your fault if it goes somewhere you don't want.
 ------------
 
 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
 
All except GC have been covered by others adequately. You are simply mistaken as regards the GC. If you take a look here, http://www.digitalmars.com/d/phobos/std_gc.html you will find the API for controlling the builtin GC. As you can see there, it is possible to turn the GC on and off at arbitrary points in your code. I will leave you to explore the other aspects of the API.
 ----------------------------------------------------------
 
 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

 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.
 
Valid points for your situation. If you don't have the time or inclination to put in the effort to translate headers for library code, that is your prerogative. It is true for you that to gain the features you would like would take that effort. However, I think you are making the wrong conclusion because of some missing details. D is not about any one or two features. It needs to be taken as a whole entity. I think that you will find if you code in D for any length of time that the language just feels "nice." It is well thought out, consistent, and efficient. You WILL save time debugging because of the unittesting and DbC features. You WILL save time not having to integrate those two features into the language from a third party library as you would with C/C++. You WILL save time because the compilation process of D is orders of magnitude faster than C/C++, especially for large projects. The combined weight of these and other efficiencies within the D domain will eclipse the time and effort put in to translate some headers for legacy code. However, I obviously don't know how extensive your library base is. And maybe for you having a mature toolset is absolutely essential to being productive. In my experience though, by using a good programmers editor with macros and tools, coupled with the Build tool on www.dsource.org, as well as the builtin bug crushing features of D, I don't miss a RAD IDE. Thanks for being candid, and I welcome you to join us in discussing the direction of D. I hope that I have helped you understand where we stand better. I also hope that you will stick around and contribute because I believe that D is the best bet for the majority of programming in the 21st century. -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
May 14 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Kyle Furlong wrote:

 First of all Ben:
 
 Welcome to the D community!
 
 I would like to apologize for the less than optimal welcome you have
 received so far; they should know better. 
Well, most people _do_ have a sore spot for ignorant rants masked as "gentle critique"s (although I hope the post wasn't meant as an ignorant rant). Ben, I think you're off the spot on most of your observations, and if you really care about D, you should also have taken the time to ask a few questions, not just assume that everything is the way it looks. When that is said, some of your observations are correct, and D need more contributors, so why not help D along. Most people on this newsgroup tend to respond positively to positive and constructive suggestions, and contributions. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
parent reply Ben Cooley <Ben_member pathlink.com> writes:
Hi Lars,

I'm rooting around for a more practical language that can be integrated into a
very large mixed C/C++ codebase.  D just can't do what I need it to do, and it's
really too bad because I have followed D and really actually do like it.

The code base we work with has several problems, one being the inclusion of more
than 20 external C and C plus plus third party libraries, as well as utilization
of the linux and windows api's.  And more importantly occasional instability due
to the use of C unsafe programming practices.

I'm posting this because I suspect that the quiet majority of C plus plus
programmers out there agree with me.  We simply aren't interested in
participating in a crusade to make D popular.  We just want something that can
do what we really need, and there are an awful lot of C and C plus plus projects
out there that depend on being able to parse C and C plus plus headers and
likely always will be.

I'm not trying to offend anyone, and I really don't expect anyone to agree
necessarily.  Just want to put forward my opinion as to what made a language
like C plus plus with its radical new programming paradigm popular.. and how D
deviates from this path.


Kyle Furlong wrote:

 First of all Ben:
 
 Welcome to the D community!
 
 I would like to apologize for the less than optimal welcome you have
 received so far; they should know better. 
Well, most people _do_ have a sore spot for ignorant rants masked as "gentle critique"s (although I hope the post wasn't meant as an ignorant rant). Ben, I think you're off the spot on most of your observations, and if you really care about D, you should also have taken the time to ask a few questions, not just assume that everything is the way it looks. When that is said, some of your observations are correct, and D need more contributors, so why not help D along. Most people on this newsgroup tend to respond positively to positive and constructive suggestions, and contributions. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
next sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <e4a4q4$27d3$1 digitaldaemon.com>, Ben Cooley says...
Hi Lars,

I'm rooting around for a more practical language that can be integrated into a
very large mixed C/C++ codebase.  D just can't do what I need it to do, and
>it's really too bad because I have followed D and really actually do like it.

The code base we work with has several problems, one being the inclusion of
>more than 20 external C and C plus plus third party libraries, as well as
>utilization of the linux and windows api's.  And more importantly occasional
>instability due to the use of C unsafe programming practices.

I'm posting this because I suspect that the quiet majority of C plus plus
programmers out there agree with me.  We simply aren't interested in
participating in a crusade to make D popular.  We just want something that can
do what we really need, and there are an awful lot of C and C plus plus projects
out there that depend on being able to parse C and C plus plus headers and
likely always will be.

I'm not trying to offend anyone, and I really don't expect anyone to agree
necessarily.  Just want to put forward my opinion as to what made a language
like C plus plus with its radical new programming paradigm popular.. and how D
deviates from this path.
It just seems like your "gentle critique" of D is that it needs to inherit the whole of monster full C/C++ compatibility. And add more meta-programming capabilities. And add more safety. And finalize the standard (which I guess is an imaginary that exists only in your mind since D is already so far away from what you want). And create more libraries (but why would more libraries be needed if it were so compatible to C/C++?). So in short, I can't tell that you actually like anything about what D currently is, so you might as well design your dream language from scratch because I don't think that D has anything to offer you. (So why are you here anyway?) jcc7
May 15 2006
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Ben Cooley wrote:

 Hi Lars,
 
 I'm rooting around for a more practical language that can be integrated
 into a
 very large mixed C/C++ codebase.  D just can't do what I need it to do,
 and it's really too bad because I have followed D and really actually do
 like it.
 
 The code base we work with has several problems, one being the inclusion
 of more than 20 external C and C plus plus third party libraries, as well
 as utilization
 of the linux and windows api's.  And more importantly occasional
 instability due to the use of C unsafe programming practices.
 
 I'm posting this because I suspect that the quiet majority of C plus plus
 programmers out there agree with me.  We simply aren't interested in
 participating in a crusade to make D popular.  We just want something that
 can do what we really need, and there are an awful lot of C and C plus
 plus projects out there that depend on being able to parse C and C plus
 plus headers and likely always will be.
 
 I'm not trying to offend anyone, and I really don't expect anyone to agree
 necessarily.  Just want to put forward my opinion as to what made a
 language like C plus plus with its radical new programming paradigm
 popular.. and how D deviates from this path.
Yeah, I see that you have an immediate need, see my other answer to you on how I think you should fix it ;) IMHO, you shouldn't mix C and C++ in this discussion, they are two different kind of problems (or C's problems in this regard is a subset to those of C++). You can link C object files directly, you only need the API declared in D, and in many cases this conversion is trivial. This is because C at the bottom is a simple language. C++ is not a simple language, and neither is D. Both has a common stem in C, but they wildly diverge in design goals, and in many places in functionality. This makes it difficult, no matter what, to make them play nice together. The brute force solution is to make wrappers, which usually involves exposing the C++ lib as C functions, and then wrap it back in D objects. wxD do this. But you make one faulty assumption regarding the life of D and it's growth, and that is that all D fans actually comes from C/C++ land. Equally many dissatisfied with the speed options. And I think quite a few from the scripting camp might take an interest too, when projects such as DSP get into release. D is a different language (although it is perfect for C++ users), and it's possible uses range much further. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Lars Ivar Igesund wrote:
 Ben Cooley wrote:
 
 Hi Lars,

 I'm rooting around for a more practical language that can be integrated
 into a
 very large mixed C/C++ codebase.  D just can't do what I need it to do,
 and it's really too bad because I have followed D and really actually do
 like it.

 The code base we work with has several problems, one being the inclusion
 of more than 20 external C and C plus plus third party libraries, as well
 as utilization
 of the linux and windows api's.  And more importantly occasional
 instability due to the use of C unsafe programming practices.

 I'm posting this because I suspect that the quiet majority of C plus plus
 programmers out there agree with me.  We simply aren't interested in
 participating in a crusade to make D popular.  We just want something that
 can do what we really need, and there are an awful lot of C and C plus
 plus projects out there that depend on being able to parse C and C plus
 plus headers and likely always will be.

 I'm not trying to offend anyone, and I really don't expect anyone to agree
 necessarily.  Just want to put forward my opinion as to what made a
 language like C plus plus with its radical new programming paradigm
 popular.. and how D deviates from this path.
Yeah, I see that you have an immediate need, see my other answer to you on how I think you should fix it ;) IMHO, you shouldn't mix C and C++ in this discussion, they are two different kind of problems (or C's problems in this regard is a subset to those of C++). You can link C object files directly, you only need the API declared in D, and in many cases this conversion is trivial. This is because C at the bottom is a simple language. C++ is not a simple language, and neither is D. Both has a common stem in C, but they wildly diverge in design goals, and in many places in functionality. This makes it difficult, no matter what, to make them play nice together. The brute force solution is to make wrappers, which usually involves exposing the C++ lib as C functions, and then wrap it back in D objects. wxD do this. But you make one faulty assumption regarding the life of D and it's growth, and that is that all D fans actually comes from C/C++ land. Equally many dissatisfied with the speed options. And I think quite a few from the scripting camp might take an interest too, when projects such as DSP get into release. D is a different language (although it is perfect for C++ users), and it's possible uses range much further.
This last paragraph is so true. I am one of these people who come from -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
May 15 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Ben Cooley wrote:
 I'm rooting around for a more practical language that can be integrated into a
 very large mixed C/C++ codebase.  D just can't do what I need it to do, and
it's
 really too bad because I have followed D and really actually do like it.
 
 The code base we work with has several problems, one being the inclusion of
more
 than 20 external C and C plus plus third party libraries, as well as
utilization
 of the linux and windows api's.  And more importantly occasional instability
due
 to the use of C unsafe programming practices.
 
 I'm posting this because I suspect that the quiet majority of C plus plus
 programmers out there agree with me.  We simply aren't interested in
 participating in a crusade to make D popular.  We just want something that can
 do what we really need, and there are an awful lot of C and C plus plus
projects
 out there that depend on being able to parse C and C plus plus headers and
 likely always will be.
 
 I'm not trying to offend anyone, and I really don't expect anyone to agree
 necessarily.  Just want to put forward my opinion as to what made a language
 like C plus plus with its radical new programming paradigm popular.. and how D
 deviates from this path.
I understand where you're coming from. I agree that if D could parse C and C++ header files out of the box, that would increase the rate of D's acceptance. The trouble is that if we were to do it, then we'd have to give up what D is and what makes D so cool. C++ has reached the end of the road in what can be done while maintaining C compatibility and compatibility with older C++ code. That said, D can be (and is) compatible with the C abi, which is a lot link to C object files. You *can* access C objects and C functions directly. You *can* access C++ objects directly if they adhere to the COM interface. You *can* hook up with any C++ code that exposes an extern "C" interface.
May 15 2006
prev sibling parent reply sailormoontw <sailormoontw_member pathlink.com> writes:
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.
May 15 2006
next sibling parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e4a7kv$2aq9$1 digitaldaemon.com>, sailormoontw says...
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.
I think you should name some names of these older programs that you're trying to get to work. Some of the older work has been abandoned, but some of it might exist somewhere else in an updated form. Or someone might be able to quickly help you update it. (By the way, it's probably a good idea to actually start a new thread if your post isn't really related to the previous thread.) jcc7
May 15 2006
parent sailormoontw <sailormoontw_member pathlink.com> writes:
In article <e4a9sl$2d83$1 digitaldaemon.com>, jcc7 says...
I think you should name some names of these older programs that you're trying to
get to work. Some of the older work has been abandoned, but some of it might
exist somewhere else in an updated form. Or someone might be able to quickly
help you update it.

(By the way, it's probably a good idea to actually start a new thread if your
post isn't really related to the previous thread.)

jcc7
Thanks for the reply, but another post of mine is sent before I read this message so I didn't change the subject of that post. I apologize for that.
May 15 2006
prev sibling next sibling parent reply sailormoontw <sailormoontw_member pathlink.com> writes:
For example, about the DirectX Wrapper what I can find the latest one is one in
a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, I've
searched the D Forum and there seems no newer version of DirectX wrapper. I
downloaded the hdk library, and when I linked the library with its sample codes,
the optlink fails with a runtime exception. I know it must be the version
imcompatible, and then, I try to recompile the source. Not only did I find some
codes need to rewrite but after all the codes seemed fixed to get a successful
compilation, some the samples still cannot run at all. I find its for the
mqoreader.d, but should I spend time to debug it??

Nope, it's hard to debug other's code, and I can feel the frustration of the
author of hdk for the frequent changing of D. I think that's the reason he or
she stopped upgrading. And if I want to upgrade the codes, I think I will face
the same problem, and not to say there isn't a good debugger to help.

Well, maybe I should not choose DirectX, SDL with derelict library seems more
stable and ready. I still hope there is a good DirectX wrapper to use...
May 15 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
sailormoontw wrote:

 Nope, it's hard to debug other's code, and I can feel the frustration of
 the author of hdk for the frequent changing of D. I think that's the
 reason he or she stopped upgrading. And if I want to upgrade the codes, I
 think I will face the same problem, and not to say there isn't a good
 debugger to help.
But this is nothing to be surprised over? The D compiler is still in beta, and D the language don't have a perfectly stable specification yet. I dare say you shouldn't be frustrated with beta software, it is almost by definition not compatible with it's own earlier versions, and is neither expected to work flawlessly. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
May 15 2006
prev sibling next sibling parent reply jcc7 <jcc7_member pathlink.com> writes:
In article <e4aac7$2dm3$1 digitaldaemon.com>, sailormoontw says...
For example, about the DirectX Wrapper what I can find the latest one is one
>in a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, I've
searched the D Forum and there seems no newer version of DirectX wrapper. I
downloaded the hdk library, and when I linked the library with its sample
>codes, the optlink fails with a runtime exception. 
Does it provide an error message? Please include that information. Are you trying to use a Microsoft-style .lib file? You'd probably need to convert the MS (COFF format) .lib to the OMF format that Digital Mars tools need. Fortunately, there's a tool that can help. From http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.announce/2405: "I've written a small utility that will convert import libraries in Microsoft COFF format to the OMF format used by the Digital Mars linker. This should make it much easier to keep import libraries updated with whatever the latest from Microsoft is. "ftp://ftp.digitalmars.com/coffimplib.zip "Consider it a beta. Let me know about any problems with it."
I know it must be the version imcompatible, and then, I try to recompile the
>source. Not only did I find some codes need to rewrite but after all the codes
>seemed fixed to get a successful compilation, some the samples still cannot
>run at all. I find its for the mqoreader.d, but should I spend time to debug
>it??
I think it's actually some kind of .lib file in the wrong format instead, but I could be wrong.
Nope, it's hard to debug other's code, and I can feel the frustration of the
author of hdk for the frequent changing of D. I think that's the reason he or
she stopped upgrading. And if I want to upgrade the codes, I think I will face
the same problem, and not to say there isn't a good debugger to help.
Eventually, we'll have a D 1.0 release, and that'll fix some of these problems of outdated source.
Well, maybe I should not choose DirectX, SDL with derelict library seems more
stable and ready. I still hope there is a good DirectX wrapper to use...
Maybe. I don't really have any experience with DirectX or SDL, so I don't know anything about this topic. But I know that others do have experience with these issues, so I think you can find various suitable libraries and bindings. You might just stumble into some old files first. But updated file are often available. If you ask us, we'll help you locate them. jcc7
May 15 2006
parent sailormoontw <sailormoontw_member pathlink.com> writes:
In article <e4adug$2h9k$1 digitaldaemon.com>, jcc7 says...
In article <e4aac7$2dm3$1 digitaldaemon.com>, sailormoontw says...
For example, about the DirectX Wrapper what I can find the latest one is one
>in a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, I've
searched the D Forum and there seems no newer version of DirectX wrapper. I
downloaded the hdk library, and when I linked the library with its sample
>codes, the optlink fails with a runtime exception. 
Does it provide an error message? Please include that information. Are you trying to use a Microsoft-style .lib file? You'd probably need to convert the MS (COFF format) .lib to the OMF format that Digital Mars tools need. Fortunately, there's a tool that can help.
I See, but what I mentioned abou the imcompatible library isn't the DirectX one that for C/C++ to use, it's http://hp.vector.co.jp/authors/VA031566/hdklib.zip, a D DirectX Wrapper Library, which was generated in 2005 Jan, and now even I fixed some codes, it still cannot be used. I think I need to spend more time if I want to use the code.
May 15 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"sailormoontw" <sailormoontw_member pathlink.com> wrote in message 
news:e4aac7$2dm3$1 digitaldaemon.com...
 For example, about the DirectX Wrapper what I can find the latest one is 
 one in
 a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, 
 I've
 searched the D Forum and there seems no newer version of DirectX wrapper. 
 I
 downloaded the hdk library, and when I linked the library with its sample 
 codes,
 the optlink fails with a runtime exception. I know it must be the version
 imcompatible, and then, I try to recompile the source. Not only did I find 
 some
 codes need to rewrite but after all the codes seemed fixed to get a 
 successful
 compilation, some the samples still cannot run at all. I find its for the
 mqoreader.d, but should I spend time to debug it??

 Nope, it's hard to debug other's code, and I can feel the frustration of 
 the
 author of hdk for the frequent changing of D. I think that's the reason he 
 or
 she stopped upgrading. And if I want to upgrade the codes, I think I will 
 face
 the same problem, and not to say there isn't a good debugger to help.

 Well, maybe I should not choose DirectX, SDL with derelict library seems 
 more
 stable and ready. I still hope there is a good DirectX wrapper to use...
I wrote/am writing a DirectX9 engine called nonagon, you can download it here: http://jamesdunne.no-ip.org/nonagon/projects.php. It has, among other things (like an engine ;) ), a fairly up-to-date, if somewhat incomplete, conversion of the D3D9 and D3DX9 headers, as well as the DInput headers. It's based on the June 2005 release of the DX9 SDK, so it's a little behind, but not much has changed in the SDK since then. The libraries that come with the DX SDK are not compatible with D, as jcc alluded to in his post. You must instead (as nonagon does) use the libraries created for Borland compilers, as that's the format that the D linker understands. The libs included with nonagon are those Borland-style libs.
May 15 2006
next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Jarrett Billingsley escribió:
 The libraries that come with the DX SDK are not compatible with D, as jcc 
 alluded to in his post.  You must instead (as nonagon does) use the 
 libraries created for Borland compilers, as that's the format that the D 
 linker understands.  The libs included with nonagon are those Borland-style 
 libs. 
 
 
Is it so? I remember trying to use Delphi and Borland C++ libs with optlink and I never got anywhere. And viceversa. I wander what went wrong... -- Carlos Santander Bernal
May 15 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:e4b6vm$21c$1 digitaldaemon.com...
 Is it so? I remember trying to use Delphi and Borland C++ libs with 
 optlink and I never got anywhere. And viceversa. I wander what went 
 wrong...
Maybe it was because they used some Delphi/C++ specific things. The DirectX libraries, at least, are mostly import libraries to DLLs, and as such, don't do much incompatible stuff.
May 15 2006
prev sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Jarrett Billingsley wrote:
 "sailormoontw" <sailormoontw_member pathlink.com> wrote in message 
 news:e4aac7$2dm3$1 digitaldaemon.com...
 For example, about the DirectX Wrapper what I can find the latest one is 
 one in
 a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, 
 I've
 searched the D Forum and there seems no newer version of DirectX wrapper. 
 I
 downloaded the hdk library, and when I linked the library with its sample 
 codes,
 the optlink fails with a runtime exception. I know it must be the version
 imcompatible, and then, I try to recompile the source. Not only did I find 
 some
 codes need to rewrite but after all the codes seemed fixed to get a 
 successful
 compilation, some the samples still cannot run at all. I find its for the
 mqoreader.d, but should I spend time to debug it??

 Nope, it's hard to debug other's code, and I can feel the frustration of 
 the
 author of hdk for the frequent changing of D. I think that's the reason he 
 or
 she stopped upgrading. And if I want to upgrade the codes, I think I will 
 face
 the same problem, and not to say there isn't a good debugger to help.

 Well, maybe I should not choose DirectX, SDL with derelict library seems 
 more
 stable and ready. I still hope there is a good DirectX wrapper to use...
I wrote/am writing a DirectX9 engine called nonagon, you can download it here: http://jamesdunne.no-ip.org/nonagon/projects.php. It has, among other things (like an engine ;) ), a fairly up-to-date, if somewhat incomplete, conversion of the D3D9 and D3DX9 headers, as well as the DInput headers. It's based on the June 2005 release of the DX9 SDK, so it's a little behind, but not much has changed in the SDK since then. The libraries that come with the DX SDK are not compatible with D, as jcc alluded to in his post. You must instead (as nonagon does) use the libraries created for Borland compilers, as that's the format that the D linker understands. The libs included with nonagon are those Borland-style libs.
Cool project Jarrett! -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
May 15 2006
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
sailormoontw wrote:
 For example, about the DirectX Wrapper what I can find the latest one is one in
 a Japanese site. http://hp.vector.co.jp/authors/VA031566/d_direct3d9/, I've
 searched the D Forum and there seems no newer version of DirectX wrapper. I
 downloaded the hdk library, and when I linked the library with its sample
codes,
 the optlink fails with a runtime exception. I know it must be the version
 imcompatible, and then, I try to recompile the source. Not only did I find some
 codes need to rewrite but after all the codes seemed fixed to get a successful
 compilation, some the samples still cannot run at all. I find its for the
 mqoreader.d, but should I spend time to debug it??
 
 Nope, it's hard to debug other's code, and I can feel the frustration of the
 author of hdk for the frequent changing of D. I think that's the reason he or
 she stopped upgrading. And if I want to upgrade the codes, I think I will face
 the same problem, and not to say there isn't a good debugger to help.
 
 Well, maybe I should not choose DirectX, SDL with derelict library seems more
 stable and ready. I still hope there is a good DirectX wrapper to use...
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.
May 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
May 16 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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? 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.
May 16 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 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?
Yes.
 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?
Yes.
 It seems to me that that's another C/C++ annoyance that D could abolish.
May 16 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
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
May 16 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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?)
May 15 2006
parent reply Sean Kelly <sean f4.ca> writes:
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
May 15 2006
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
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 +/
May 15 2006
prev sibling next sibling parent reply nick <nick.atamas gmail.com> writes:
Ben Cooley wrote:
 There are a few major problems with D that still prevent it from being
practical
 for use in the real world.
[SNIP] It seems like these complaints come up often, and they are mostly unjustified. Walter, perhaps you should address all of these in a FAQ-like section on the D site. If you already have a section like that, give it more visibility. Just a thought. Nick.
May 15 2006
parent Walter Bright <newshound digitalmars.com> writes:
nick wrote:
 Ben Cooley wrote:
 There are a few major problems with D that still prevent it from being
practical
 for use in the real world.
[SNIP] It seems like these complaints come up often, and they are mostly unjustified. Walter, perhaps you should address all of these in a FAQ-like section on the D site. If you already have a section like that, give it more visibility. Just a thought.
There is www.digitalmars.com/d/faq.html. If you want to add to it by paraphrasing what's going on in this thread, I'll be very happy to accept the improvements!
May 15 2006
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Ben Cooley" <Ben_member pathlink.com> wrote in message 
news:e48h8g$pk$1 digitaldaemon.com...
 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
 --------------------------------------------
[snip] Do you mind if I email you? I'd like to talk about these issues you raise wrt something slightly off-topic for D. If you don't feel like posting your email my address is ben dot hinkle at gmail dot com. thanks! -Ben
May 15 2006
prev sibling parent Nilo <Nilo_member pathlink.com> writes:
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/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

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

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.
May 16 2006