Reusing concepts from different compile units yields multiple defined symbols

[christoph.heindl@…]

Currently I use the ublas concepts defined in ublas/detail/concepts.hpp to derive concepts based on ublas concepts such as

template<class X> struct Vector : boost::numeric::ublas::VectorConcept<X> {};

In my unit test project I have different compile units that use BOOST_CONCEPT_ASSERT to assure Vector concept compliance. This yields multiple defined symbols for the following methods (and full specialized versions):

ublas/detail/concepts.hpp: void concept_checks(); template<class T> ZeroElement(T); template<class T> OneElement(T);

inlining those solves the problem (for me). I'm compiling on MSVC9.0. Current trunk seems to have this methods still not-inlined.

[Gunter]

(In [56578]) see #3501: Reusing concepts from different compile units yields multiple defined symbols

• added BOOST_UBLAS_INLINE macros to requested locations

[Gunter]

@Christoph: please check if the committed version fixes your problem. If not, please provide a small example to reproduce the problem.

[anonymous]

@Gunter Committed version fixes my problem. I did not test on a fresh trunk checkout. All I did was replacing concepts.hpp of 1.39.0 by current head revision. Thanks for your help.

[Gunter]

(In [56614]) fix #3499 and fix #3501:

• added inline to free helper functions
• added missing concept check
• fixed broken internal checks

[christoph.heindl@…]

Hi Gunter,

I fear we need to reopen the bug. In Debug the same linker error as reported occurs because BOOST_UBLAS_INLINE is not defined to inline at all.

Therefore I suggest attributing the free functions with inline explicitely, unless someone knows a better solution.

best regards, Christoph

[anonymous]

In config.hpp you can find the lines

#ifdef NDEBUG

#ifndef BOOST_UBLAS_INLINE
#define BOOST_UBLAS_INLINE inline
#endif
...

This means that inline is disabled in debug builds in order to be able to follow the execution path. Explicitely defining

#define BOOST_UBLAS_INLINE inline

before including any uBLAS header should solve the problem.

[christoph.heindl@…]

It would solve the problem indeed.

I wonder, however, if requiring the user to do the bugfixing for a third-party library in his code is the best way to handle this.

[Gunter]

(In [57202]) see #3501: Reusing concepts from different compile units yields multiple defined symbols (Incomplete)

• removed inlines that were added with the last commit
• added anonymous namespace to make functions local to compilation unit

[Gunter]

(In [57208]) see #3501: Reusing concepts from different compile units yields multiple defined symbols (Incomplete)

• updated documentation

[Gunter]

(In [61114]) see #3501: moved release note entry to correct release

[Gunter]

(In [61115]) fix #3501: merge changes 57202,57208,61114 into release

boost/numeric/ublas/detail/concepts.hpp libs/numeric/ublas/doc/release_notes.htm