Couldn't htod be enhanced in a way that it would also convert source files, doing all the cumbersome activities like
merging class definitions and method implementations, replacing types with proper D types, converting macros to functions, some #ifdefs to versions, etc.

Trass3r Wrote:

> Couldn't htod be enhanced in a way that it would also convert source files, doing all the cumbersome activities like
> merging class definitions and method implementations, replacing types with proper D types, converting macros to functions, some #ifdefs to versions, etc.

Having spent six months developing a significant app in D only to find impediments to practical completion of the project and ultimate deployment, I would find a tool to convert D to C++ even more useful.

Sorry, I gotta tell ya.

Justin Johansson

Justin Johansson wrote:
> Having spent six months developing a significant app in D only to find impediments to
> practical completion of the project and ultimate deployment,

Which ones did you find to be blocking?

Walter Bright Wrote:

> Justin Johansson wrote:
> > Having spent six months developing a significant app in D only to find impediments to practical completion of the project and ultimate deployment,
> 
> Which ones did you find to be blocking?

(My time zone is way different to yours and gotta dash to work soon so will have to be brief).

(Comments in relation to D1)

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.

#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.

#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

#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

#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 .. so I guess a comment about the outlandish size of executable files produced by the D compiler and general immature (lack of) optimization of generated code by D compiler is apt for this point as well.

Cheers,

Justin Johansson

"Justin Johansson" <no@spam.com> wrote in message news:hn6evv$hl7$1@digitalmars.com...
> Walter Bright Wrote:
>
>> Justin Johansson wrote:
>> > Having spent six months developing a significant app in D only to find
>> > impediments to
>> > practical completion of the project and ultimate deployment,
>>
>> Which ones did you find to be blocking?
>
> (My time zone is way different to yours and gotta dash to work soon so will have to be brief).
>
> (Comments in relation to D1)
>
> 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.
>

When you have a chance, I'm curious to hear why you feel something like FastCGI is unappealing to customers compared to .so. I assume there's more to it than it just not being "trendy" enough. (For me personally, the issue is moot b/c my clients are generally on shared hosting from questionable providers, so I pretty much have to stick with PHP or Haxe. Or ASP, depending on the client).

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.

Walter Bright:
>but the priority right now is finalizing D2.<

Having a bit of roadmap can't hurt, it can even help. So, what are the missing things?

Bye,
bearophile

On 03/09/2010 03:35 PM, Justin Johansson wrote:
> #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
>
>
> Justin Johansson
>

I hate the restriction on modules with static constructors and cyclic dependencies. IMO it's the most patronizing 'feature' D has. A year or so ago I ran into this issue during my first (and last) big project in D. Just last week I started working on it again and replaced everything that got initialized in a static constructor with stuff akin to

static Foobar foobar(){
  static Foobar _foobar;
  static bool inited = false;
  if(!inited){
    _foobar = new Foobar();
    _foobar.init();
    inited = true;
  }
  return _foobar;
}


(on a side note, string mixins are turning out to be quite handy)

It killed the cyclic dependency problems, but I expect this pattern isn't a good thing to have littered all over the place.

Ellery Newcomer wrote:
> I hate the restriction on modules with static constructors and cyclic dependencies. IMO it's the most patronizing 'feature' D has.

I understand, but the alternative is the essentially random order of execution that C++ has.

On 03/09/2010 06:15 PM, Walter Bright wrote:
> Ellery Newcomer wrote:
>> I hate the restriction on modules with static constructors and cyclic
>> dependencies. IMO it's the most patronizing 'feature' D has.
>
> I understand, but the alternative is the essentially random order of
> execution that C++ has.

Would you contend that the alternative that I showed above is not random order?