[boost] Re: Any interest in static_list?

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
questions:

    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
www.boost-consulting.com