Boost logo

Boost :

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

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