View mode: basic / threaded / horizontal-split · Log in · Help
March 09, 2010
any tool to at least partially convert C++ to D (htod for source files)?
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.
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source files)?
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
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source files)?
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?
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source
"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).
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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
March 09, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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?
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home