Re: Bug#116823: Debian's g++-3.0 forgets to generate some code.
> I don't like this `construct on first use' idiom at all, aesthetically.
Isn't this exactly what you want, and what modules.h does? If module A
uses module B, construction of A first constructs B.
> I find it disgusting to use a function call for that and a
> preprocessor symbol.
Well, you don't have to use the preprocessor symbol :-(
Actually, many people find direct access to variables (members or
globals) disgusting, and prefer to use accessor functions all the
time.
> But maybe I'll do something else in the mid-term future. We've been using
> this `construct on first use' idiom until recently in GiNaC for flyweights
> and last week I finally got rid of them by setting them up similarly to
> how libstdc++-v3 sets up cin, cout, etc (i.e. section 27.4.2.1.6).
Doesn't this, in practice, require placement new calls? That appears
to be very unreliable, as it still allows for objects to be accessed
before being constructed.
> Arguably, that order is too simplistic. It should analyze the
> dependencies among the globals, see if they form a DAG and rearrange the
> order so that the DAG is traversed correctly when the library/program
> fires up.
The problem here is: the globals don't have dependencies, atleast none
that are expressed in C++. For your application, it seems to be
sufficient: the module.h logic also orders constructors with
translation-unit granularity, instead of object granularity.
Regards,
Martin
Reply to: