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