www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - any tool to at least partially convert C++ to D (htod for source files)?

reply Trass3r <un known.com> writes:
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.
Mar 09 2010
parent reply Justin Johansson <no spam.com> writes:
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
Mar 09 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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?
Mar 09 2010
parent reply Justin Johansson <no spam.com> writes:
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)


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.


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.


think, if I
recall correctly, that it was to do with static class members so had to pull a
lot of source



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.


design


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
Mar 09 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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)


 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).
Mar 09 2010
parent Justin Johansson <no spam.com> writes:
Nick Sabalausky Wrote:


 "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)


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


Hi Nick,

The product I'm developing is a library that will be/can be integrated into a
number of Apache modules (e.g. mod_python) for webby-type applications
(e.g. SOA) and needs to execute in-process.  It cannot be easily integrated
in-process-wise with FastCGI.  The only other option is to offer it as
statically linked
library but for a variety of reasons (convenience of deployment, commercial
etc),
dynamic linking via a shared library is really the only way to go.

Probably my choice of words (unappealing) may have misled you into thinking
that FastCGI might have been an option for me but it is not.

Cheers, JJ
Mar 10 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Justin Johansson wrote:


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.




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.




think, if I
 recall correctly, that it was to do with static class members so had to pull a
lot of source



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.




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.




template design


This has gotten a lot better in the last 3 months or so.



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.
Mar 09 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Mar 09 2010
parent Jesse Phillips <jessekphillips+D gmail.com> writes:
bearophile wrote:


 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


There is a reasonably up-to-date community driven roadmap. Don has done
a lot of work on it.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
Mar 09 2010
prev sibling next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 10.03.2010 0:57, Walter Bright wrote:

 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.


Mixed-in state that requires static initialization is a problem. Neither 
of the solutions you have listed seems to work well in that scenario:

1. Access to the lazily initialized data must be synchronized, which is 
not always a way to go.

2. A third module cannot be used. At least, we haven't been able to 
figure out how to do that. Probably, something could be hacked up if 
this bug (feature) is fixed 
http://d.puremagic.com/issues/show_bug.cgi?id=2671

3. Forcing the user to initialize each mixed-in piece manually is a 
potential source of grievance.
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:

 2. A third module cannot be used. At least, we haven't been able to 
 figure out how to do that. Probably, something could be hacked up if 
 this bug (feature) is fixed 
 http://d.puremagic.com/issues/show_bug.cgi?id=2671


Thanks, I'll have a look at it.
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Walter Bright wrote:

 Max Samukha wrote:

 2. A third module cannot be used. At least, we haven't been able to 
 figure out how to do that. Probably, something could be hacked up if 
 this bug (feature) is fixed 
 http://d.puremagic.com/issues/show_bug.cgi?id=2671


 
 Thanks, I'll have a look at it.


The example in the bug report works on D1 and D2. I cannot reproduce the 
error. I marked it as "worksforme"; if I've got the test case wrong 
please reopen it.
Mar 10 2010
parent reply Max Samukha <spambox d-coding.com> writes:
On 10.03.2010 13:13, Walter Bright wrote:

 Walter Bright wrote:

 Max Samukha wrote:

 2. A third module cannot be used. At least, we haven't been able to
 figure out how to do that. Probably, something could be hacked up if
 this bug (feature) is fixed
 http://d.puremagic.com/issues/show_bug.cgi?id=2671


 Thanks, I'll have a look at it.


 The example in the bug report works on D1 and D2. I cannot reproduce the
 error. I marked it as "worksforme"; if I've got the test case wrong
 please reopen it.


My example is incorrect, sorry. b and c should be circularly imported:

module a;

template Foo(int i)
{
     static this()
     {
     }
}

void main() { }
----

module b;

import a;
import c;

alias Foo!(1) foo;
----

module c;

import a;
import b;

alias Foo!(2) foo;
----
Error: circular initialization dependency with module b

Following the logic that Foo is not a mixin template, I hoped to cheat 
the compiler so that the static constructors ran during a's 
initialization, avoiding the circular dependency error. I was wrong.

Still looking for a solution. Basically, there should be a way to enable 
the following:

module a;

template Foo()
{
     static int a;
     static this()
     {
        a = 42;
     }
}

----
module b;
import c;
import a;

mixin Foo;

----
module c;
import b;
import a;

mixin Foo;
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:

 Still looking for a solution. Basically, there should be a way to enable 
 the following:
 
 module a;
 
 template Foo()
 {
     static int a;
     static this()
     {
        a = 42;
     }
 }
 
 ----
 module b;
 import c;
 import a;
 
 mixin Foo;
 
 ----
 module c;
 import b;
 import a;
 
 mixin Foo;


template Foo()
{
     static int _a;
     static int a()
     {
         static bool _a_inited;
         if (!_a_inited)
         {    _a_inited = true;
              _a = 42;
         }
         return _a;
     }
}
Mar 10 2010
parent reply Max Samukha <spambox d-coding.com> writes:
On 10.03.2010 21:28, Walter Bright wrote:

 template Foo()
 {
 static int _a;
 static int a()
 {
 static bool _a_inited;
 if (!_a_inited)
 { _a_inited = true;
 _a = 42;
 }
 return _a;
 }
 }


Lazy initialization requires some kind of synchronization when a is 
shared. Static initialization does not have that drawback.
Mar 10 2010
next sibling parent Justin Johansson <no spam.com> writes:
Max Samukha Wrote:


 On 10.03.2010 21:28, Walter Bright wrote:

 template Foo()
 {
 static int _a;
 static int a()
 {
 static bool _a_inited;
 if (!_a_inited)
 { _a_inited = true;
 _a = 42;
 }
 return _a;
 }
 }


 
 Lazy initialization requires some kind of synchronization when a is 
 shared. Static initialization does not have that drawback.


Indeed and synchronization is costly.
Mar 10 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:

 Lazy initialization requires some kind of synchronization when a is 
 shared. Static initialization does not have that drawback.


That's correct (otherwise you have the double checked locking bug).

Wrapping the function body in a synchronized statement will do the trick.

(Yes, it's slower.)
Mar 10 2010
parent reply Eldar Insafutdinov <e.insafutdinov gmail.com> writes:
Walter Bright Wrote:


 Max Samukha wrote:

 Lazy initialization requires some kind of synchronization when a is 
 shared. Static initialization does not have that drawback.


 
 That's correct (otherwise you have the double checked locking bug).
 
 Wrapping the function body in a synchronized statement will do the trick.
 
 (Yes, it's slower.)


The issue is that we need it in a performance critical part of QtD. The library
mixes in static constructors to initialise user-defined classes. This means
that we can't use it when user code is in cyclic dependency. static
constructors are very useful, but giving a possibility to override it's current
behaviour would make them applicable to more use-cases(if you look into that
bug report, another person was trying to use them exactly as we do, and faced
the same problems).
Mar 10 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Eldar Insafutdinov wrote:

 The issue is that we need it in a performance critical part of QtD.
 The library mixes in static constructors to initialise user-defined
 classes. This means that we can't use it when user code is in cyclic
 dependency. static constructors are very useful, but giving a
 possibility to override it's current behaviour would make them
 applicable to more use-cases(if you look into that bug report,
 another person was trying to use them exactly as we do, and faced the
 same problems).


I hear you. I'll try to come up with a better solution.
Mar 10 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 3/9/10 23:57, Walter Bright wrote:

 Justin Johansson wrote:


 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.




 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.




 detail but think, if I
 recall correctly, that it was to do with static class members so had
 to pull a lot of source



 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?
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:

 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?



I don't know if there's a reasonable way of determining if they depend 
on each other, so dmd assumes they do.
Mar 10 2010
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 03/10/2010 12:14 PM, Walter Bright wrote:

 Jacob Carlborg wrote:

 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?



 I don't know if there's a reasonable way of determining if they depend
 on each other, so dmd assumes they do.


Maybe do a bit of analysis that can tell whether any static ctors in a 
module use symbols from any other module and use that to determine 
module dependencies? It wouldn't fix the problem completely, but it 
would make it a bit more fine grained, and would probably remove 90% of 
the false positives.
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:

 Maybe do a bit of analysis that can tell whether any static ctors in a 
 module use symbols from any other module and use that to determine 
 module dependencies?


This is a transitive thing. Furthermore, if you do anything nontrivial, 
you'll be referencing other module symbols. And finally, if you add some 
debugging code like a print statement, suddenly your code will no longer 
run.
Mar 10 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 03/10/2010 01:10 PM, Walter Bright wrote:

 Ellery Newcomer wrote:

 Maybe do a bit of analysis that can tell whether any static ctors in a
 module use symbols from any other module and use that to determine
 module dependencies?


 This is a transitive thing.


Hmm. That would make things obnoxious.

Furthermore, if you do anything nontrivial,

 you'll be referencing other module symbols. And finally, if you add some
 debugging code like a print statement, suddenly your code will no longer
 run.


Your code never ran in the first place otherwise. Or it did until you 
added some static constructors to initialize some field or other.


Just in case I didn't state my suggestion clearly (I think I did)

As I understand it, when a static constructor is found in a module A, 
then every imported module B must have its static constructor run prior 
to A's. So say you represent that as a flag associated with import B, or 
a directed edge in a graph, or whatever. If A has no static constructors 
then it doesn't participate in the ordering.

My suggestion is that when a symbol from import B is found in A's static 
constructor then B must be ordered before A, but otherwise not. I guess 
transitivity would require you to check the declaration of each local 
symbol that gets called in A's static constructor, or in general, 
everything in A. Come to think of it, that kind of information might be 
useful in the context of IDEs and 'find all usages of this symbol'. I 
might do this..

It wouldn't fix everything, but it would prune the number of 
dependencies that get castigated unjustly.

Don't think it's worthwhile? Maybe it isn't.
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:

 I guess 
 transitivity would require you to check the declaration of each local 
 symbol that gets called in A's static constructor,


Everything referenced by everything referenced, etc., in the 
constructor, all the way.

It's not even possible to do in full generality, because the D compiler 
won't have the source to everything.
Mar 10 2010
parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Wed, 10 Mar 2010, Walter Bright wrote:


 Ellery Newcomer wrote:

 I guess transitivity would require you to check the declaration of each
 local symbol that gets called in A's static constructor,


 
 Everything referenced by everything referenced, etc., in the constructor, all
 the way.
 
 It's not even possible to do in full generality, because the D compiler won't
 have the source to everything.


In the D spirit of things, ie, stay conservative:

If you can prove that the closure of code that the static constructor 
touches doesn't escape the file, which you can do fairly easily and you 
can guarantee that you've got all the code for that check, then the ctor 
could be flagged as self-contained and take itself out of the running for 
loop detection.

Later, potentially more aggressive logic could be written, time and/or 
volunteers permitting.

Later,
Brad
Mar 10 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:

 In the D spirit of things, ie, stay conservative:
 
 If you can prove that the closure of code that the static constructor 
 touches doesn't escape the file, which you can do fairly easily and you 
 can guarantee that you've got all the code for that check, then the ctor 
 could be flagged as self-contained and take itself out of the running for 
 loop detection.
 
 Later, potentially more aggressive logic could be written, time and/or 
 volunteers permitting.


There is a problem with that - the error message about circular 
dependencies will come and go in a fairly erratic manner (at least from 
the user's perspective).
Mar 10 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 3/10/10 19:14, Walter Bright wrote:

 Jacob Carlborg wrote:

 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?



 I don't know if there's a reasonable way of determining if they depend
 on each other, so dmd assumes they do.


I suspected that. How dangerous would it be with a compiler option that 
allowed the above and the programmer have to make sure that they don't 
depend on each other?
Mar 10 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:

 How dangerous would it be with a compiler option that 
 allowed the above and the programmer have to make sure that they don't 
 depend on each other?


The idea is to eliminate implementation-defined behavior as much as 
practical. I don't think it's at all easy for a programmer to look at a 
non-trivial static constructor and determine unequivocably that it does 
not depend on any imports.
Mar 10 2010
parent Jacob Carlborg <doob me.com> writes:
On 3/10/10 23:50, Walter Bright wrote:

 Jacob Carlborg wrote:

 How dangerous would it be with a compiler option that allowed the
 above and the programmer have to make sure that they don't depend on
 each other?


 The idea is to eliminate implementation-defined behavior as much as
 practical. I don't think it's at all easy for a programmer to look at a
 non-trivial static constructor and determine unequivocably that it does
 not depend on any imports.


The reason I suggested to add a compiler switch is because I usually 
have very simple static constructors.
Mar 11 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 03/09/2010 03:35 PM, Justin Johansson wrote:


think, if I
 recall correctly, that it was to do with static class members so had to pull a
lot of source



 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.
Mar 09 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Mar 09 2010
next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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?
Mar 09 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ellery Newcomer wrote:

 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?


Doesn't look random to me.

By "random" I mean it is implementation-defined, and in practice it 
depends on the order the linker assembles things in, which is not at all 
easily controlled.
Mar 09 2010
parent reply BCS <none anon.com> writes:
I just had a crazy thought: how about allow things to explicitly state
static-constructor 
dependencies? By default, it would work as it does now, all constructors 
in all imported modules get run before any in this module but if an explicit 
list is given, then only that list need be run first.

My first thought was to only do this at the module level with something like 
this:

module foo.bar : foo.baz, foo.baz; // run first, even thought not imported

import foo.bar;
import foo.bing; // constructors need not be run first

It might be handy to allow finer grained specification of both the ends, 
maybe putting the list per constructor and allowing the list to include classes 
for instance.

-- 
... <IXOYE><
Mar 10 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 I just had a crazy thought: how about allow things to explicitly state 
 static-constructor dependencies?


My first thought is that this will be both very annoying (see the 
exception specification failure in Java) and will inevitably be written 
wrong by the user.
Mar 10 2010
prev sibling parent Justin Johansson <no spam.com> writes:
BCS Wrote:


 I just had a crazy thought: how about allow things to explicitly state
static-constructor 
 dependencies? By default, it would work as it does now, all constructors 
 in all imported modules get run before any in this module but if an explicit 
 list is given, then only that list need be run first.
 
 My first thought was to only do this at the module level with something like 
 this:
 
 module foo.bar : foo.baz, foo.baz; // run first, even thought not imported
 
 import foo.bar;
 import foo.bing; // constructors need not be run first
 
 It might be handy to allow finer grained specification of both the ends, 
 maybe putting the list per constructor and allowing the list to include
classes 
 for instance.


It's not a crazy idea at all, unless I am crazy also :-)

This is similar to the idea that I am now using in C++ to solve the same
problem,
albeit a bit of a hack since there is no language support for it.  My idea (in
C++)
is simply to have an abstract Module class which has a virtual method
initialize() 
that concrete Module classes implement.  Then you statically instantiate a
single instance of each Module.  At runtime, these instances are constructed
in some linker dependent order (this being a manifestation of the original
problem).
But then in the constructor for Module, you list the dependencies upon other
Module
classes and use this information to create a direct acyclic graph (DAG) for
ultimate
invocation of the initialize() methods of all your "modules" in dependency order
(upon entering main()).

Also you can use placement operator new to construct "static objects" out of
static
memory (if need be), this being called in the appropriate implementation of the
initialize() method for the respective "module".

Works for me but YMMV.

Cheers
Justin Johansson
Mar 10 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 3/10/10 01:15, 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.


How does Java handle this ?
Mar 10 2010
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jacob Carlborg wrote:

 On 3/10/10 01:15, 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.


 
 How does Java handle this ?


Static initialization blocks are associated to classes. They are run 
when the class is loaded. So it depends on the order classes are loaded 
in your program (it's the order in which you instantiate them).

---
public class A {
	static {
		System.out.println("A loading");
		B b = new B();
		System.out.println("A loaded");
	}
}

public class B {
	static {
		System.out.println("B loading");
		A a = new A();
		System.out.println("B loaded");
	}
}

public class C {
	
	public static void main(String[] args) {
		A a = new A();
// Prints:
// A loading
// B loading
// B loaded
// A loaded
	}

}

public class D {
	
	public static void main(String[] args) {
		B b = new B();
// Prints:
// B loading
// A loading
// A loaded
// B loaded
	}

}
Mar 10 2010
parent Jacob Carlborg <doob me.com> writes:
On 3/10/10 17:22, Ary Borenszweig wrote:

 Jacob Carlborg wrote:

 On 3/10/10 01:15, 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.


 How does Java handle this ?


 Static initialization blocks are associated to classes. They are run
 when the class is loaded. So it depends on the order classes are loaded
 in your program (it's the order in which you instantiate them).

 ---
 public class A {
 static {
 System.out.println("A loading");
 B b = new B();
 System.out.println("A loaded");
 }
 }

 public class B {
 static {
 System.out.println("B loading");
 A a = new A();
 System.out.println("B loaded");
 }
 }

 public class C {

 public static void main(String[] args) {
 A a = new A();
 // Prints:
 // A loading
 // B loading
 // B loaded
 // A loaded
 }

 }

 public class D {

 public static void main(String[] args) {
 B b = new B();
 // Prints:
 // B loading
 // A loading
 // A loaded
 // B loaded
 }

 }


I forgot for a second that Java forces you to put everything in classes.
Mar 10 2010
prev sibling parent reply grauzone <none example.net> writes:
Ellery Newcomer wrote:

 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;
 }


You could move the static ctor into another module outside of the cycle 
(e.g. the module where your main() function is). Then you get the same 
effects as "platform" dependent initialization.

It would be very practical if D has a "lose" version of the static ctor, 
that works even with cyclic dependencies. One could compare the module 
names or so to make the ordering deterministic across all linkers/platforms.

PS: I wonder why it's not considered a problem to execute unittests in 
random order? It's confusing if unittests fail "out of order", and the 
high level test fails first, even if the actual error is in some other 
low level module with its own unittests.
Mar 10 2010
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 03/10/2010 05:14 PM, grauzone wrote:

 You could move the static ctor into another module outside of the cycle
 (e.g. the module where your main() function is). Then you get the same
 effects as "platform" dependent initialization.


most of my static ctors just set a logger object meant for use within 
the module. In retrospect, it was kind of a boneheaded thing to do, 
since the loggers all get initialized inside the logger module anyways.

Actually, all of it was to work around the idiom

static Object singleton = new Object();

which doesn't have a 1-1 correspondence in D. I've converted most of 
them to enums..
Mar 10 2010
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Justin Johansson wrote:

 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)
 

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.


Can you send me an example of such large source file?
Mar 10 2010
parent Jacob Carlborg <doob me.com> writes:
On 3/10/10 13:55, Ary Borenszweig wrote:

 Justin Johansson wrote:

 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)


 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.


 Can you send me an example of such large source file?


I usually have problems with this file when it contains errors: 
http://hg.dsource.org/projects/dwt-mac/file/969e7de37c3d/dwt
internal/cocoa/OS.d 


It usually contains errors after a merge of SWT when I'm updating DWT to 
a new version. I never have problems with the original java file.
Mar 10 2010
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 3/9/10 22:35, Justin Johansson wrote:

 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)


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.


I also have this problem with some of my D files. But on the other hand 
I've never seen a tool/IDE for C++ that can do to what descent does. 
I.e. showing both syntax and semantic errors as you type.


 Cheers,

 Justin Johansson
Mar 10 2010
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
 

 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 also had done a fair amount of work, and foundered on the inability to 
dynamically load anything without it being a big deal.

Like you say, it has been brought up many many times. Everyone says yes, 
this is a real show-stopper, then the thread dies down and so on.

Steve
Mar 10 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 3/10/10 16:33, Steve Teale wrote:


 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 also had done a fair amount of work, and foundered on the inability to
 dynamically load anything without it being a big deal.

 Like you say, it has been brought up many many times. Everyone says yes,
 this is a real show-stopper, then the thread dies down and so on.

 Steve


What are the exact problems that people have with shared libraries on 
linux? I've made a few dynamic libraries on Mac OS X of which only one 
didn't work (I have no idea why). Among the working libraries were DWT 
and Tango.
Mar 10 2010
parent reply Justin Johansson <no spam.com> writes:
Jacob Carlborg Wrote:


 On 3/10/10 16:33, Steve Teale wrote:


 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 also had done a fair amount of work, and foundered on the inability to
 dynamically load anything without it being a big deal.

 Like you say, it has been brought up many many times. Everyone says yes,
 this is a real show-stopper, then the thread dies down and so on.

 Steve


 
 What are the exact problems that people have with shared libraries on 
 linux? I've made a few dynamic libraries on Mac OS X of which only one 
 didn't work (I have no idea why). Among the working libraries were DWT 
 and Tango.


DMD on Linux does not support the creation of shared libraries.
Mar 10 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 3/10/10 22:59, Justin Johansson wrote:

 Jacob Carlborg Wrote:


 On 3/10/10 16:33, Steve Teale wrote:


 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 also had done a fair amount of work, and foundered on the inability to
 dynamically load anything without it being a big deal.

 Like you say, it has been brought up many many times. Everyone says yes,
 this is a real show-stopper, then the thread dies down and so on.

 Steve


 What are the exact problems that people have with shared libraries on
 linux? I've made a few dynamic libraries on Mac OS X of which only one
 didn't work (I have no idea why). Among the working libraries were DWT
 and Tango.


 DMD on Linux does not support the creation of shared libraries.


Is that the runtime or the compiler? What about GDC, too old?
Mar 11 2010
parent reply Justin Johansson <no spam.com> writes:
Jacob Carlborg Wrote:


 On 3/10/10 22:59, Justin Johansson wrote:

 Jacob Carlborg Wrote:


 On 3/10/10 16:33, Steve Teale wrote:


 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 also had done a fair amount of work, and foundered on the inability to
 dynamically load anything without it being a big deal.

 Like you say, it has been brought up many many times. Everyone says yes,
 this is a real show-stopper, then the thread dies down and so on.

 Steve


 What are the exact problems that people have with shared libraries on
 linux? I've made a few dynamic libraries on Mac OS X of which only one
 didn't work (I have no idea why). Among the working libraries were DWT
 and Tango.


 DMD on Linux does not support the creation of shared libraries.


 
 Is that the runtime or the compiler? What about GDC, too old?


AFAIK, it is the linker; something about Linux/Unix ELF object file formats
perhaps .. though I'm
out of my depth now.  Maybe others can explain better.

I've never used GDC so cannot say what the issues might be there.

Think this thread needs a new subject line to raise the visibility of the
issue.  Granted
though that Walter has acknowledged the issue (at long last).

Understandably Walter has lots on his plate; what can be done to help out?

Cheers, Justin
Mar 11 2010
next sibling parent Igor Lesik <curoles yahoo.com> writes:
=0A> >>> I also had done a fair amount of work, and foundered on the =










inability to=0A> >>> dynamically load anything without it being a big deal.=
=0A> >>>=0A> >>> Like you say, it has been brought up many many times. Ever=
yone says yes,=0A> >>> this is a real show-stopper, then the thread dies do=
wn and so on.=0A> >>>=0A> >>> Steve=0A> >>=0A> >> What are the exact proble=
ms that people have with shared libraries on=0A> >> linux? I've made a few =
dynamic libraries on Mac OS X of which only one=0A> >> didn't work (I have =
no idea why). Among the working libraries were DWT=0A> >> and Tango.=0A> >=
=0A> > DMD on Linux does not support the creation of shared libraries.=0A> =
=0A> Is that the runtime or the compiler? What about GDC, too old?=0A=0A>AF=
AIK, it is the linker; something about Linux/Unix ELF object file formats p=
erhaps .. though I'm=0A>out of my depth now.=A0 Maybe others can explain be=
tter.=0A=0A>I've never used GDC so cannot say what the issues might be ther=
e.=0A=0A>Think this thread needs a new subject line to raise the visibility=
 of the issue.=A0 Granted=0A>though that Walter has acknowledged the issue =
(at long last).=0A=0A>Understandably Walter has lots on his plate; what can=
 be done to help out?=0A=0AI work on making shared libraries work on Linux.=
 IMO, -fPIC does not quite do what=0Ait has to do (ie does not make EBX PIC=
 register). I let Walter know; waiting on reply=0Afrom him (I do not want t=
o change compiler code without his blessing).=0A=0AIgor=0A=0A=0A
Mar 11 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 3/11/10 14:12, Justin Johansson wrote:

 Jacob Carlborg Wrote:


 On 3/10/10 22:59, Justin Johansson wrote:

 Jacob Carlborg Wrote:


 On 3/10/10 16:33, Steve Teale wrote:


 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 also had done a fair amount of work, and foundered on the inability to
 dynamically load anything without it being a big deal.

 Like you say, it has been brought up many many times. Everyone says yes,
 this is a real show-stopper, then the thread dies down and so on.

 Steve


 What are the exact problems that people have with shared libraries on
 linux? I've made a few dynamic libraries on Mac OS X of which only one
 didn't work (I have no idea why). Among the working libraries were DWT
 and Tango.


 DMD on Linux does not support the creation of shared libraries.


 Is that the runtime or the compiler? What about GDC, too old?


 AFAIK, it is the linker; something about Linux/Unix ELF object file formats
perhaps .. though I'm
 out of my depth now.  Maybe others can explain better.

 I've never used GDC so cannot say what the issues might be there.

 Think this thread needs a new subject line to raise the visibility of the
issue.  Granted
 though that Walter has acknowledged the issue (at long last).

 Understandably Walter has lots on his plate; what can be done to help out?

 Cheers, Justin


I think what we can do to help is to track down exactly what the 
problems are and make sure Walter knows about them. If possible we could 
also try to fix them.

The problems I have are:

Undefined symbols:
__deh_beg
__deh_end
__Dmain
__minfo_beg
__minfo_end
Mar 11 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 3/11/10 22:34, Jacob Carlborg wrote:

 On 3/11/10 14:12, Justin Johansson wrote:

 Jacob Carlborg Wrote:


 On 3/10/10 22:59, Justin Johansson wrote:

 Jacob Carlborg Wrote:


 On 3/10/10 16:33, Steve Teale wrote:


 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 also had done a fair amount of work, and foundered on the
 inability to
 dynamically load anything without it being a big deal.

 Like you say, it has been brought up many many times. Everyone
 says yes,
 this is a real show-stopper, then the thread dies down and so on.

 Steve


 What are the exact problems that people have with shared libraries on
 linux? I've made a few dynamic libraries on Mac OS X of which only one
 didn't work (I have no idea why). Among the working libraries were DWT
 and Tango.


 DMD on Linux does not support the creation of shared libraries.


 Is that the runtime or the compiler? What about GDC, too old?


 AFAIK, it is the linker; something about Linux/Unix ELF object file
 formats perhaps .. though I'm
 out of my depth now. Maybe others can explain better.

 I've never used GDC so cannot say what the issues might be there.

 Think this thread needs a new subject line to raise the visibility of
 the issue. Granted
 though that Walter has acknowledged the issue (at long last).

 Understandably Walter has lots on his plate; what can be done to help
 out?

 Cheers, Justin


 I think what we can do to help is to track down exactly what the
 problems are and make sure Walter knows about them. If possible we could
 also try to fix them.

 The problems I have are:

 Undefined symbols:
 __deh_beg
 __deh_end
 __Dmain
 __minfo_beg
 __minfo_end


Just after I wrote the above I tried to add the symbols as weak symbols 
like this:

void* _deh_beg __attribute__ ((weak));
void* _deh_end __attribute__ ((weak));
void* _Dmain __attribute__ ((weak));
void* _minfo_beg __attribute__ ((weak));
void* _minfo_end __attribute__ ((weak));

Phobos then compiled and I tried a "hello world" application and it it 
worked. I don't know if there are some other parts that don't work.
Mar 11 2010
prev sibling parent reply Igor Lesik <curoles yahoo.com> writes:
I think what we can do to help is to track down exactly what the =0A>probl=


ems are and make sure Walter knows about them. If possible we could =0A>als=
o try to fix them.=0A>The problems I have are:=0A>Undefined symbols:=0A>__d=
eh_beg=0A>__deh_end=0A>__Dmain=0A>__minfo_beg=0A>__minfo_end=0A=0AUndefined=
 symbols is not the fundumental problem, it is possible to make them=0Aseen=
 as defined. I=A0was able to make=A0shared runtime library as .so.=0AThe pr=
oblem is that the very first library funciton call from Dmain is not going =
to work,=0Abecause=A0EBX is not PIC register.=0A=0A=0A
Mar 11 2010
parent Jacob Carlborg <doob me.com> writes:
On 3/11/10 22:52, Igor Lesik wrote:

 I think what we can do to help is to track down exactly what the
 problems are and make sure Walter knows about them. If possible we could
 also try to fix them.
 The problems I have are:
 Undefined symbols:
 __deh_beg
 __deh_end
 __Dmain
 __minfo_beg
 __minfo_end


 Undefined symbols is not the fundumental problem, it is possible to make them
 seen as defined. I was able to make shared runtime library as .so.
 The problem is that the very first library funciton call from Dmain is not
going to work,
 because EBX is not PIC register.


I found out how to solved the undefined symbols problem, see my other 
post where I replied to myself. A "hello world" application worked for 
me, I guess it might have something to do with that the code is PIC as 
default on Mac OS X.
Mar 11 2010