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