[boost] Re: Any interest in static_list?

From: David Abrahams (dave_at_[hidden])
Date: 2003-09-29 06:39:20

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

> "John H. Spicer" <jhs_at_[hidden]> writes:
>> 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.
>
> Out-of-line definition of inline function can be forced. For example, every 
> shared library where static_list is used may have its own out-of-line 
> definiton of <code>inline void multiply_defined() {}</code>. 
> While linking a shared library this definition cannot be optimized away just 
> because at the time of linking it's unknown whether main program has it or 
> not. As a result, every shared library where multiply_defined is used 
> out-of-line has it. This is truly multiply defined function.
> The dilemma for a linker is which multiply_defined to use. Only one among 
> all these definitions should be used, otherwise you could end up with two 
> different addresses for one function and comparison might give unexpected 
> result (not sure about this, correct me if I'm wrong).

You're wrong, sorry.  There's no requirement that all invocations of
multiply_defined execute at the same PC locations, because that's not
detectable behavior for a C++ program.  The only requirement is that
everyone who takes the address of multiply_defined gets the same
value.  It could be that all direct calls to multiply_defined are
actually inlined.  I'm not sure how that affects your problem, though.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com