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

[Walter Bright]

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.