On 3/9/10 23:57, 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.
I've always wonder why that is. I mean if I put an empty static
constructor in two modules and they import each other I get a circular
reference error. Usually when I use static constructors they don't
depend on the order of each other. Can't this be fixed if the static
constructors don't depend on each other?
