Review of Andrei's std.benchmark

Jonathan M Davis jmdavisProg at gmx.com
Fri Sep 21 13:43:49 PDT 2012


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


More information about the Digitalmars-d mailing list