any tool to at least partially convert C++ to D (htod for source

[Justin Johansson]

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.