generic way to access C++ libs?

Jacek Generowicz 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

    [1] they appear in different translation units
    [2] they are token-for-token identical
    [3] the meanings of those tokens are the same in both translation
        units.

  [...]

  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 mailing list