View mode: basic / threaded / horizontal-split · Log in · Help
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
> 
> The #1 show-stopper for me was lack of shared object (.so) support under
> Linux; virtually mandated by my audience (Apache/LAMP).  (A workaround
> like FastCGI is simply not appealing to customers.)  This topic
> discussed many times before on this NG.
> 
> 
I 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
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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
	}

}
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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;
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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)
> >
> > The #1 show-stopper for me was lack of shared object (.so) support under 
> > Linux; virtually
> > mandated by my audience (Apache/LAMP).  (A workaround like FastCGI is 
> > simply not
> > appealing to customers.)  This topic discussed many times before on this 
> > NG.
> >
> 
> When you have a chance, I'm curious to hear why you feel something like 
> FastCGI is unappealing to customers compared to .so. I assume there's more 
> to it than it just not being "trendy" enough. (For me personally, the issue 
> is moot b/c my clients are generally on shared hosting from questionable 
> providers, so I pretty much have to stick with PHP or Haxe. Or ASP, 
> depending on the client). 

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
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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.
March 10, 2010
Re: any tool to at least partially convert C++ to D (htod for source
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;
    }
}
March 10, 2010
Re: static this [was: any tool to at least partially convert C++ to D]
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><
1 2 3 4 5 6
Top | Discussion index | About this forum | D home