Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-25 14:27:08

Alexander Nasonov <alnsn-mycop_at_[hidden]> writes:

> I'm waiting for positive answer ;)

Here's what I have so far. Not what we hoped for, I guess:

"John H. Spicer" <jhs_at_[hidden]> writes:

> David Abrahams wrote:
>> Alexander Nasonov just posted something to Boost which was so
>> astounding that I felt I _had_ to check it out with the CWG. It's a
>> long-standing desire of many programmers that they be able to simply
>> link a translation unit containing some static initialization into
>> their program, without disturbing the program's other translation
>> units in any way, and be sure that the static initializations in the
>> new translation unit would take place at program startup. Long ago I
>> gave up on this as a pipe dream, because 3.6.2/3 seemed to say that I
>> would have to invoke a function defined in the new translation unit
>> elsewhere in my program.
>> Alexander's technique seems to rely on the fact (?) that an inline
>> function is defined in *all* translation units where it's used. Is
>> there a problem with his idea? Do implementations actually support
>> it?
> I don't agree with that interpretation of 3.6.2. I have always
> assumed that the 3.6.2 was intended to permit an implementation that
> loads object files on-demand, so that the use of an unresolved
> reference to a function or object would cause the object file to be
> loaded and the static initializations to be performed. In such a
> model, a use of an inline function would only cause the object file to
> be loaded if it happened that the implementation required an
> out-of-line definition in that object file.

I have always made the same assumption. I am left with the following

    1. Is our assumption about intent correct?

    2. Regardless of what the intent may have been, is Alexander's
       interpretation supported by the standard text (it seems to be)?

    3. Do we have a defect?

    4. Can something reasonably be done to make this coding idiom work
       in a future standard without compromising on-demand loading?

I ask #4 because it *really* is very desirable to have the capability.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at