www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: any tool to at least partially convert C++ to D (htod for source

Thanks for your comments Walter.

Certainly I'm not on about berating D; I have quite an affection for D and high
hopes
for the success of D as it matures over time.  It is, of course, important for
you to
know what show-stoppers people are finding (which is why you asked).

Also, while I'm not currently actively developing with D, I still enjoy
watching this channel,
especially some of the episodes featuring skits by retard, bearophile and other
cool boffins**

http://en.wikipedia.org/wiki/Boffin  (**taking the complimentary meaning of the
word).

If I had more time available I'd happily contribute in some concrete way
(code/bug fixes etc)
to the common cause of D but alas that might have to wait for another lifetime.

 #2 significant deterioration of D's GC under high working dataset volume.  The
GC did
 not seem to scale very well.  Since moving back to C++ I've implemented my own
 memory management technique (note I said memory management not *automatic* GC).
 One of the biggest reasons for using D in the first place (automatic GC) no
longer held for me.
 This topic also discussed much before on this NG.

It is possible to do your own memory management with D.

Agreed; but so is the case with C++, my point being that automatic GC (in D) is no longer (for me) the number one reason to use D.
 There've been a lot of proposals for improved gc, but not really anyone 
 willing to step up and do the work. On the plus side, D's gc has proven 
 to be remarkably robust and reliable. It's a solid, if pedestrian, 
 implementation.

Actually I've solved the memory management problem in C++ to the degree that suits my purposes. I developed the idea quite independently of others (I did this a few months ago when having decided to go back to C++). Having developed the technique myself, thought that no doubt it must already have a name. After a bit of web searching I happened across the term "region based memory management". I don't have the references handy still, but believe it's used in Cyclone and has been proposed for "real-time Java". If I were to revert to D in the future, I would definitely have this in my D toolbox.
 I'm going to argue a bit with dmd not having optimization. It actually 
 does have a well developed and reliable data flow analysis driven 
 optimizer. It does register allocation based on live range analysis, and 
 it even has a sophisticated instruction scheduler in it. Where it's 
 deficient is in floating point code gen, but the rest is pretty good.

I won't argue the issue; probably I made some wrong assumptions / interpretations re my D experience. Regards Justin Johansson Walter Bright Wrote:
 Justin Johansson wrote:
 The #1 show-stopper for me was lack of shared object (.so) support under
Linux; virtually
 mandated by my audience (Apache/LAMP).  (A workaround like FastCGI is simply
not
 appealing to customers.)  This topic discussed many times before on this NG.

I know this is a big problem and I know it's been discussed a lot, I just wanted to be sure what was stopping you.
 #2 significant deterioration of D's GC under high working dataset volume.  The
GC did
 not seem to scale very well.  Since moving back to C++ I've implemented my own
 memory management technique (note I said memory management not *automatic* GC).
 One of the biggest reasons for using D in the first place (automatic GC) no
longer held for me.
 This topic also discussed much before on this NG.

It is possible to do your own memory management with D. There've been a lot of proposals for improved gc, but not really anyone willing to step up and do the work. On the plus side, D's gc has proven to be remarkably robust and reliable. It's a solid, if pedestrian, implementation.
 #3 problems with circular module references.  I forget some of the detail but
think, if I
 recall correctly, that it was to do with static class members so had to pull a
lot of source
 code into one big file .. then leading to problem #4

The circular module thing is usually a result of static constructors in each of two modules that import each other. There are many solutions to this, such as switching to lazy initialization, moving the initializations to a 3rd module, having the initialization done by a function called explicitly from main(), etc.
 #4 The performance of the IDE that I was using (Descent under Eclipse) did not
scale
 very well with large source files.  Tried a few other development tools but
found Descent
 to be overall the best but, like I say, not adequate at scaling in a large
project.
 Sure this is not a D language problem per se but a practical issue that is
still likely to
 put some users off.

 #5 problems with circular references when dealing with a complex class
template design

This has gotten a lot better in the last 3 months or so.
 #6 a general feeling of "gee, I never had any of these problems with C++" ..
this comment
 relating to the general immaturity (bugs-wise) of the D compiler compared with
what's
 available for C++ these days ..

In the last 10 years C++ compilers have gotten a lot better. Before 2000, they all suffered from endless bugs.
 so I guess a comment about the outlandish size of executable
 files produced by the D compiler

I have some ideas about improving the size, but the priority right now is finalizing D2.
 and general immature (lack of) optimization of generated
 code by D compiler is apt for this point as well.

I'm going to argue a bit with dmd not having optimization. It actually does have a well developed and reliable data flow analysis driven optimizer. It does register allocation based on live range analysis, and it even has a sophisticated instruction scheduler in it. Where it's deficient is in floating point code gen, but the rest is pretty good.

Mar 10 2010