On 03/07/12 16:37, VimalMathew@Eaton.com wrote:

Hi,

 

I have this line of code in my header file: project(C, range(0, A_rows), range(0, A_cols)) = A;

 

I’ve specified:

#include <boost/numeric/ublas/storage.hpp>

using namespace boost::numeric::ublas;  at the beginning of the header file


It is generally regarded as bad form in most cases to have using namespace within a header file. There are some exceptions when having a very specific nested namespace with few symbols to protect against accidental argument-dependent lookup, but generally it shouldn't be done.

 

When I compile my .cpp file, I get an error message saying: “c:\users\c9995799\desktop\level 1 problem for mpi\dmatrix.hpp(34): error C2784: 'const boost::numeric::ublas::matrix_range<M> boost::numeric::ublas::project(const boost::numeric::ublas::matrix_range<M> &,const matrix_range<M>::range_type &,const matrix_range<M>::range_type &)' : could not deduce template argument for 'const boost::numeric::ublas::matrix_range<M> &' from 'boost::numeric::ublas::matrix<T>'”

 

This error goes away if I substitute boost::numeric::ublas::range instead of just range here: project(C, range(0, A_rows), range(0, A_cols)) = A;

 

How do I get this to work the way it currently is?

 


You don't! This is why the first paragraph is the general conclusion. This is the current state of C++ namespaces. I have always found this rather disappointing since one is frequently forced to qualify the namespace upon each use. This is therefore little better than adding a prefix and not having namespaces.

Seriously, it is best that you don't do it that way. If you insist then depending on your use of namespaces you could add "using boost::numeric::ublas::range;" This might work, but might have ambiguities. Otherwise in the function where you use ublas you could move the using namespace statement. My experience is that even if this does compile on GCC that the Microsoft compilers often go completely insane as a result of the using directive/declarations. Additionally someone else may define another range function in another namespace that is a better match within header files included directly or indirectly. It's excessively fragile and un-portable to have such widespread using clauses.

Thanks,

Vimal

 

I agree with your expectation. If namespaces and argument-dependent lookup were specified as I would have hoped it wouldn't be an issue.

I hope this helps,

Neil Groves