Re: Bug#116823: Debian's g++-3.0 forgets to generate some code.
Hi,
On Thu, 25 Oct 2001, Martin v. Loewis wrote:
> > 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.
Sure it is.
> > 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.
For CLN that would be tolerable for the globals. With a #define it would
only break binary compatibility. Accessors are fine but exaggerated usage
of accessors leads to bad style IMHO. I always shiver when I have to read
student's programs in a style they learned in their C++ courses: having a
one-to-one correspondence between accessors and data. This is not real
abstraction and only under special circumstances something is gained with
that style.
In GiNaC, when I transformed all flyweights from `construct on first use'
statics to direct objects, that didn't only lead to better readabilty but
also to a 10-15% gain in performance. :-)
> > 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.
It doesn't necessarily require placement new calls, though that is
what libstdc++-v3 does in src/ios.cc. Sometimes it's enough to declare
extern const T& foo;
in the header file and
T* foo_p;
const T& foo = *foo_p;
in the module. foo_p must be allocated of course before the reference is
set up. And yes, of course, that may lead to unreliable code if people
tamper with that moduel without knowing what's going on. :-(
> > 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.
Hmm, I have observed the AIX linker doing rearrangements of modules of
this kind and Bruno Haible claims he has / had a patch for GNU ld that
does exactly this so it seems like things can be done better, doesn't it?
Cheers
-richy.
--
.''`. Richard B. Kreckel
: :' : <kreckel@debian.org>
`. `' <kreckel@ginac.de>
`- <http://www.ginac.de/~kreckel/>
Reply to: