Re: [eigen] The horrors of an XLC port/compatibility

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/1/22 Aron Ahmadia <aja2111@xxxxxxxxxxxx>:
> Hi Benoit,
>
> <some snipping>
>>>
>>> The most common edits are regarding template template arguments:
>>> -template<typename Derived> struct AnyMatrixBase
>>> +template<template <typename, typename> class Derived> struct AnyMatrixBase
>>>
>>> The XLC compiler does not accept template template arguments if they
>>> are not parametrized (i.e., you cannot put in "typename Derived" if
>>> Derived is actually a template class).
>>
>> Sorry I don't get it. From your diff:
>>
>> -template<typename UnaryOp, typename MatrixType>
>> +template<typename UnaryOp, template <typename, typename> class Derived>
>>
>> First, i wouldn't call this template parameter Derived here. We call
>> them Derived when we have a CRTP,
>> http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
>>
>> Second, I really don't understand why the template template parameter
>> here is taking _2_ template parameters?
>>
>> Actually I don't understand the problem. Here, MatrixType is just a
>> class. It's true that we often specialize this template with
>> MatrixType = some specialization of a template, but AFAIK we never try
>> to pass a template template parameter here. So I'm confused! As to why
>> you could possibly need to do a change like this. Here's a
>> simplification of this situation:
>>
>> Eigen code:
>> template<typename M>
>> class Foo { .... };
>>
>> Foo<MatrixXd> foo1;
>> Foo<Matrix<float,3,5> > foo2;
>>
>> The fact that we're specializing Foo with M = Matrix<float,3,5>
>> doesn't mean that we're trying to pass Foo a template template
>> parameter. It shouldn't matter that M happens to be a specialization
>> of the template Matrix, as long of course as it's a full
>> specialization (which it is), not a partial specialization.
>>
>
> I do appear to be missing something, as this was how I was getting
> around other compiler errors.  Here's an example that I thought would
> crack xlc but didn't...
>
> template<class A>
> class Foo
> {
> public:
>  A x;
> };
>
> template<typename B, typename C>
> class Bar
> {
> public:
>  B y;
>  C z;
> };
>
> template<typename B, typename C>
> class FooBar : public Foo< Bar <B, C> >
> {
> public:
>  B a;
> };
>
> int main()
> {
>  Foo<int> f;
>  Foo< Bar<int,short> > g;
>  FooBar<char, float> h;
>  return 0;
> }

Indeed, this C++ code is perfectly correct, because Bar<int,short> is
just a plain class, it doesn't matter at all that it comes from the
class template Bar. Once the class template Bar has been fully
specialized (i.e. all the template parameters have been specialized),
the resulting type Bar<int,short> is just a plain class type.

> I'm guessing things get more complicated when we add things like CRTP.
>  I reverted my changes (except for the inclusion of the  IBM_XLC
> macro) and tried a pre-error compile.  Here's the XLC error message:
>
> [  0%] Building CXX object
> test/CMakeFiles/prec_inverse_4x4_2.dir/prec_inverse_4x4.cpp.o
> "/home/aron/scratch/eigen/hg/Eigen/src/Core/SelfAdjointView.h", line
> 145.79: 1540-0716 (S) The template argument "Eigen::SelfAdjointView"
> does not match the template parameter "class T".
> "/home/aron/scratch/eigen/hg/Eigen/src/Core/SelfAdjointView.h", line
> 132.110: 1540-0716 (S) The template argument "Eigen::SelfAdjointView"
> does not match the template parameter "class T".
> "/home/aron/scratch/eigen/hg/Eigen/src/Core/util/ForwardDeclarations.h",
> line 44.37: 1540-1109 (S) The use of undefined class
> "Eigen::ei_traits<Eigen::Matrix<double,4,4,1,4,4> >" is not valid.
> "/home/aron/scratch/eigen/hg/Eigen/src/Core/MatrixBase.h", line 55.12:
> 1540-0700 (I) The previous message was produced while processing
> "class Eigen::DenseBase<Eigen::Matrix<double,4,4,1,4,4> >".
> make[3]: *** [test/CMakeFiles/prec_inverse_4x4_2.dir/prec_inverse_4x4.cpp..o]
> Error 1
> make[2]: *** [test/CMakeFiles/prec_inverse_4x4_2.dir/all] Error 2
> make[1]: *** [test/CMakeFiles/check.dir/rule] Error 2
> make: *** [check] Error 2
>
> I'm not sure the line numbers are being very helpful there.

They are.
But these compilation messages clearly refer to some modifications in
Eigen's source code. Indeed, in the Eigen sources from the Mercurial
repository, at line 145 in SelfAdjointView.h, there is no "class T" at
all.

>
> You can see how I got it to work from the diff:
> -template<typename Derived> class TriangularBase : public AnyMatrixBase<Derived>
> +template<template <typename, typename> class Derived> class
> TriangularBase: public AnyMatrixBase<Derived>;
>
> But we've decided I'm doing the wrong thing here.  What would you
> suggest I try next?

You could paste here the compilation errors from trying to compile
with XLC the plain Eigen sources, with only minimal changes to get to
the point where you need help.

> It's not too hard to get external development accounts onto our
> BlueGene/P system here at KAUST, though an easier solution would be to
> get you accounts on a local IBM AIX machine with the XL compilers.

Thanks -- but in the current rush to get Eigen 3.0 done, I'm not sure
that any of us could make good use of such an account. But I can
continue to help you with error messages on this list!

Cheers,
Benoit

>
> Cheers,
> Aron
>
>
>