Hello. Eigen 3.2.2 is compiling and working in our project on Visual Studio 2012, but on Visual Studio 2010 I get the following compiler error: c:\buildroot\tsplines_adam\include\kernel\eigen\src/SparseCore/SparseDenseProduct.h(316): error C2244: 'Eigen::SparseMatrixBase<Derived>::operator *' : unable to match function definition to an existing declaration definition 'const SparseDenseProductReturnType<Derived,OtherDerived>::Type Eigen::SparseMatrixBase<Derived>::operator *(const Eigen::MatrixBase<OtherDerived> &) const' existing declarations 'const SparseDenseProductReturnType<Derived,OtherDerived>::Type Eigen::SparseMatrixBase<Derived>::operator *(const Eigen::MatrixBase<OtherDerived> &) const' 'const Eigen::SparseDiagonalProduct<Derived,OtherDerived> Eigen::SparseMatrixBase<Derived>::operator *(const Eigen::DiagonalBase<DiagonalDerived> &) const' 'const SparseSparseProductReturnType<Derived,OtherDerived>::Type Eigen::SparseMatrixBase<Derived>::operator *(const Eigen::SparseMatrixBase<OtherDerived> &) const' 'const Eigen::CwiseUnaryOp<Eigen::internal::scalar_multiple2_op<internal::traits<T>::Scalar,std::complex<internal::traits<T>::Scalar>>,const Derived> Eigen::SparseMatrixBase<Derived>::operator *(const std::complex<internal::traits<T>::Scalar> &) const' 'const Eigen::CwiseUnaryOp<Eigen::internal::scalar_multiple_op<internal::traits<T>::Scalar>,const Derived> Eigen::SparseMatrixBase<Derived>::operator *(const internal::traits<T>::Scalar &) const' Note that 3.2.0 IS working on Visual Studio 2010. This is preventing us from upgrading, as we need support for VS 2010 at least. Note that there is a Stack Overflow question that appears to be related for VS 2008; I can't vouch for it: http://stackoverflow.com/questions/25355830/eigen3-2-version-error-c2244-eigensparsematrixbasederivedoperator We do have a suspect. The exact piece of code producing the error looks like this (SparseDenseProduct.h line 290 or 316): // sparse * dense template<typename Derived> template<typename OtherDerived> inline const typename SparseDenseProductReturnType<Derived,OtherDerived>::Type SparseMatrixBase<Derived>::operator*(const MatrixBase<OtherDerived> &other) const { return typename SparseDenseProductReturnType<Derived,OtherDerived>::Type(derived(), other.derived()); } This code DID NOT CHANGE between 3.2.0 and 3.2.2. Notably, though, the following code WAS changed between 3.2.0 and 3.2.2 (SparseDenseProduct.h line 20): // THIS IS 3.2.0 template<typename Lhs, typename Rhs> struct SparseDenseProductReturnType<Lhs,Rhs,1> { typedef SparseDenseOuterProduct<Lhs,Rhs,false> Type; }; // THIS IS 3.2.2 template<typename Lhs, typename Rhs> struct SparseDenseProductReturnType<Lhs,Rhs,1> { typedef typename internal::conditional< Lhs::IsRowMajor, SparseDenseOuterProduct<Rhs,Lhs,true>, SparseDenseOuterProduct<Lhs,Rhs,false> >::type Type; }; We think there's some kind of compiler issue with VS 2010 and earlier where the conditional macro (internal::conditional) causes the symbols not to match. In particular, note that the "definition" and the first of the "existing declarations" in the compiler error are character-for-character identical; and yet, it claims it can't find a match. I assume that it is not handling this conditional as well as it should be. That's just a guess; the fundamental bug is that it's not compiling in VS 2010 :).
*** Bug 855 has been marked as a duplicate of this bug. ***
Created attachment 486 [details] Workaround Can you test the attached fix. Thank you.
The patch from Gael in comment #2 stops the compile error. But I'm not sure if my test case is good. Simply removing the method definition (but leaving the declaration) also stops the compile error for me.
Seems to be related to: https://forum.kde.org/viewtopic.php?f=74&t=122568 Fixes: https://bitbucket.org/eigen/eigen/commits/4269db373ec6/ https://bitbucket.org/eigen/eigen/commits/c02cde4e9110/ Summary: Bug 857: workaround MSVC compilation issue.
*** Bug 863 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/857.