On Friday, September 21, 2012 15:59:31 Andrei Alexandrescu wrote: > On 9/19/12 4:11 PM, "Øivind" wrote: > > New question for you :) > > > > To register benchmarks, the 'scheduleForBenchmarking' mixin inserts a > > shared static initializer into the module. If I have a module A and a > > module B, that both depend on eachother, than this will probably not > > work..? The runtime will detect the init cycle and fail with the > > following error: > > > > "Cycle detected between modules with ctors/dtors" > > > > Or am I wrong now? > > I think you have discovered a major issue. Ideas on how to attack this?
Some of us have been asking for ages for the ability to mark a static constructor as not depending on anything so that the runtime _doesn't_ think that there's a circular dependency, but Walter has been against the idea when it's been brought up. That would _really_ help here. Without redesigning std.benchmark so that it doesn't use static constructors, I don't know how you can fix that. Normally, if you really need a static constructor, you go through the pain of creating a separate module which does the initialization for you (like std.stdio does). But that won't work in this case, because you're mixing it in. So, unless you can redesign it so that std.benchmark doesn't require static constructors, it may have to be a limitation of std.benchmark that it can't be used where it would create a circular dependency. Unfortunately, the circular dependency issue makes static constructors almost useless outside of isolated cases, even though they rarely actually have circular dependencies. It's one of the few places in D that I'd say that there's a major design flaw. - Jonathan M Davis