generic way to access C++ libs?
jacek.generowicz at cern.ch
Wed Nov 10 09:57:21 CET 2004
"Diez B. Roggisch" <deets.nospaaam at web.de> writes:
> > I don't think so. Given that the _definition_ of the function is in
> > the header, and the header is needed to compile any code which might
> > want to link with the library, the compiler has all it needs, without
> > a need for a corresponding function to exist in the library.
> It has been a while, but I think what happened when including such a header
> on several locations that produced .o-files was that a duplicate symbol
> problem arised on linking time.
I find this hard to believe, unless we are talking about a buggy
compiler or linker. Remember that in the case of templates (until the
EDG people implemented the mythical "export" keyword, relatively
recently) the _only_ way to use templates in more than one translation
unit was to include the full _definitions_ of everything in the
template, in the header.
That's why C++ has the One Definition Rule (ODR). Here's what
Stroustrup has to say about the ODR in _The C++ Programming Language_
3rd edition (p203):
A given class, enumeration, and template, etc., must be defined
exactly once in a program. From a practical point of view, this
means that there must be exactly one definition of, say, a class
ersiding in a single file somewhere. Unfortunately, the language
rule cannot be that simple. [...] Consequently the rule in the
standard that says that there must be a unique definition of a
class, template, etc., is phrased in a somewhat more compliated and
subtle manner. This rule is commonly referred to as "the
one-definiton rule," the ODR. That is, two definitions of a class,
template, or inline function are accepted as examples of the same
unique definition if and only if
 they appear in different translation units
 they are token-for-token identical
 the meanings of those tokens are the same in both translation
The intent of the ODR is to allow inclusion of a class definiton in
different tranlation units from a common source file.
> Why would there be a symbol at all, when the code got "pasted" into
> the callee's code?
Remember that "inline" (and the implicit inline you generate by
_defining_ the method in the class itself) is merely a hint to the
compiler, which the compiler is perfectly entitled to ignore. One
situation in which the compiler is _guaranteed_ to ignore it is if you
also declare the method to be virtual, for example. In general, it may
choose to inlne some of the calls while not others.
I don't think that declaring a function to be inline makes any
guarantess about whether you will find a symbol for that function in
the object code. But the ODR guarantees that sorting this mess out is
the compiler's problem, not yours.
More information about the Python-list