I'm sad to report that the error reporting mechanism appears to be broken in Visual Studio 2008 Express SP1.

Code: Select all

Vector4f _2(1, 2, 3, 4); // Line 7
// ... 100 lines of stuff ...
Vector4f _3(1, 2, 3); // Line 110 - ERROR: Vec3 constructor on Vec4


Fine, easy to spot here. Now for the compile error, usual templating spew, but there's a glaring error:

Code: Select all

c:devucfexternaleigensrccorematrix.h(361) : error C2039: 'THIS_METHOD_IS_ONLY_FOR_VECTORS_OF_A_SPECIFIC_SIZE' : is not a member of 'Eigen::ei_static_assert'
    [elided]
    c:devucfexternaleigensrccorematrix.h(358) : while compiling class template member function 'Eigen::Matrix::Matrix(const float &,const float &,const float &)'
    [elided]
    c:devtest_eigen_messagestest_eigen_messages.cpp(7) : see reference to class template instantiation 'Eigen::Matrix' being compiled


The error site is reported in the final message block. On line *7*, not 110. This is consistent, it appears to be that the first template instantiation of a class which has a method with a failing static assert will trigger the assert at instantiation time *if the method with the failing assert is referenced anywhere*, that is that the instantiation of the method is bubbled up to the same location that the class is first referenced, which frankly makes sense... I'm not a language lawyer, but it seems like the kind of thing that the standard would deem acceptable?

I'm encountering this a lot due to my attempts to use a Vec4 where I was previously using a home grown Vec4 type with a constructor which allowed for a variable number of initialisers (defaulting unspecified components to zero.) I've simply been removing the static assert from the header for the moment...

Have you considered adding mixin classes for the different capabilities of different dimension matrices? It would probably make your class hierarchy quite deep, but ultimately the methods that shouldn't be available in a specific specialisation wouldn't be. Or is this what you were avoiding when you talk about designing a quick to compile template library?

xgrnds wrote:On line *7*, not 110.

Quick update:

Reading between the lines, looks like this was the problem with this post, too: new-vector2f-failing-t-39419.html

perhaps for MSVC we could implement our EIGEN_STATIC_ASSERT using the _STATIC_ASSERT macro:

http://msdn.microsoft.com/en-us/library/bb918086.aspx

something like:

Code: Select all

#ifdef _MSC_VER

#define EIGEN_STATIC_ASSERT(COND,MSG) _STATIC_ASSERT((COND) && (#MSG))

#else
 // ...
#endif

could you try that for us and see if MSVC reports better error messages using that macro ?

Note that this macro is defined in the header file.

ggael wrote:perhaps for MSVC we could implement our EIGEN_STATIC_ASSERT using the _STATIC_ASSERT macro:

Sadly, all that does is produce a far less readable error message, the error site is still at the location of the first clas instantiation. It's clear that the template method instantiation is occurring at the site of the overall class instantiation in MSVC 2k8.

The new static assert code is:

Code: Select all

#include
#define EIGEN_STATIC_ASSERT(CONDITION,MSG) _STATIC_ASSERT((CONDITION) && (#MSG));


Here's the new, unreadable version of the message using the MS _STATIC_ASSERT macro (error lines changed due to me being at work now, so i rewrote the test program):

Code: Select all

1>c:deveigen-2.0.0eigensrccorematrix.h(361) : error C2466: cannot allocate an array of constant size 0
1>        c:deveigen-2.0.0eigensrccorematrix.h(358) : while compiling class template member function 'Eigen::Matrix::Matrix(const float &,const float &,const float &)'
1>        with
1>        [
1>            _Scalar=float,
1>            _Rows=4,
1>            _Cols=1
1>        ]
1>        c:devtest_eigen_errorstest_eigen_errorstest_eigen_errors.cpp(10) : see reference to class template instantiation 'Eigen::Matrix' being compiled
1>        with
1>        [
1>            _Scalar=float,
1>            _Rows=4,
1>            _Cols=1
1>        ]


Is there a reason why the EIGEN_STATIC_ASSERT_VECTOR_SPECIFIC_SIZE macro exists rather than subdividing the implementation into size-based mixins?

Thanks.

I see, so this macro does not rely on any internal MSVC extension, and it simply uses standard c++ tricks. too bad.

Beside, the main reason is simplicity. Indeed, in that specific case we could rename the current Matrix to _Matrix, and add a simple template class Matrix inheriting _Matrix with partial specializations defining only the relevant subset of ctor. Why not...

ah, another reason is to not clutter the documentation.

actually, we have already tried to use mixins to avoid the need of such static assertions, but we gave up for various reasons. Here is the related thread: http://listengine.tuxfamily.org/lists.t ... 00001.html

And there's also the concern that deepening class hierarchies could lead to longer compile times!

It's important to say this issue seems MSVC specific, while GCC reports the correct line number. Anyway if you find a fix, we'll include it inside a #ifdef checking for MSVC.

bjacob wrote:It's important to say this issue seems MSVC specific, while GCC reports the correct line number. Anyway if you find a fix, we'll include it inside a #ifdef checking for MSVC.

Yes... well, it looks like this is the way that the template instantiations work for MSVC (and who knows, other compilers might implement it the same way, it seems a reasonable thing to do.)

If I were to fix this, then I'd have to do it at a structural level by introducing a deeper class hierarchy. I doubt it'd be possible to fix merely inside an ifdef.

ggael mentioned a single extra level of inheritance for specifically sized matrices, which sounds reasonable to me.

xgrnds wrote:If I were to fix this, then I'd have to do it at a structural level by introducing a deeper class hierarchy. I doubt it'd be possible to fix merely inside an ifdef.

Assuming you'd done this... This would fix the issue for static assertion on matrix sizes. Now what about all the other types of static assertions we have? A fix would have to fix them too, in order to be worthwile. But fixing all of these static assertions by introducing finer types would be very complicated!

To see all our types of static asserts, see in Core/util/StaticAssert.h.

Also let's keep in mind that with static asserts being part of C++0x, this problem is taking care of itself in the long term. Eigen already uses the standard static_assert if C++0x mode is enabled.