Re: [eigen] MSC compiler error: worth working around?

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

2010/4/16 Eamon Nerbonne <eamon.nerbonne@xxxxxxxxx>:
> On Fri, Apr 16, 2010 at 13:21, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 2010/4/16 Eamon Nerbonne <eamon.nerbonne@xxxxxxxxx>:
>> > Hi all,
>> > In the course of specializing some of my code to accept various eigen
>> > matrix
>> > types, I ran into an MSC bug.
>>
>> There's 1 thing I dont understand: you're not the only one using MSC,
>> so why are you the first one to hit this problem? Hauke, do you know
>> about this?
>
> Possibly it's compiler version related (not what I expect though).  However,
> it's also code that typically people outside of eigen won't use often.  In
> my case it's something like this:
> SomeNonEigenType<... , (MatrixBase<TDerived>::IsVectorAtCompileTime?1: 2) ,
> ... >
> Which I suppose just isn't that common?

hoho, a MSC bug triggered by a ternary ?: operator used in a template
parameter: this reminds me of issue 94.
https://bitbucket.org/eigen/eigen/issue/94/anymatrixbase-evalto-caught-in-infinit

Can you try moving the ?: out of the template parameter:

enum { foo = MatrixBase<TDerived>::IsVectorAtCompileTime?1: 2 };
SomeNonEigenType<... , foo , ... >


>
> Also, in eigen2, the "using Base::IsVectorAtCompileTime;" syntax wasn't
> used, but rather that was evaluated at the spot (rows == 1 || cols==1) - so
> eigen2 wouldn't have triggered this bug with MatrixBase, at least.
> Actually, that's an argument in favor of working around the bug; otherwise
> going eigen2-->eigen3 may involve compiler crashes which doesn't make
> upgrading any easier.

We want anyway to support MSC with eigen3, which means we have to work
around its bugs anyway.

>
>
>> >  Essentially, eigen's classes have lots of
>> > members in the style of "using Base::SomeEnumMember;".  Using those kind
>> > of
>> > "inherited" members as part of computations (not just unmodified usage)
>> > in
>> > template parameters in MSC triggers compiler bugs or an ICE (depending
>> > on
>> > the computation).  I submitted a simple test-case & bug report to
>> > microsoft,
>> > but that's been closed [WontFix].
>>
>> At least they didn't sue you for patent infringement (USPTO 29043801
>> "Method for triggering a bug in MSC with enums").
>
> I'm not too thrilled with their bug-resolution process either.   Still,
> sometimes they do fix em, so I do report em.
>
>> > One workaround would be to replace "using Base::SomeEnumMember;" with
>> > "enum{ SomeEnumMember = ei_traits<typename
>> > Base::Derived>::SomeEnumMember};".
>>
>> Often, the stuff is only present in a Base class, not in ei_traits. So
>> it would be:
>>  enum { SomeEnum = Base::SomeEnum };
>>
>> > Leaving it out entirely works in MSC but
>> > not in GCC, unless I'm missing something.
>>
>> Ah great! So on MSC we could replace using by just a comment opener "//"
>> ?
>>
>> Maybe the bug could be worked around by introducing a macro
>>    EIGEN_IMPORT_ENUM(Enum, From)
>
> As far as I can tell, yes, that just works.  I'm not sure if that's due to
> MSC being too leniant or GCC's in error, but it doesn't work that way in
> GCC.

Try my suggestion above, though. Let's see if its the same as bug #94.

Benoit

>
>>
>> >  Alternatively, wouldn't it be
>> > possible to remove these helpers entirely and just always refer to
>> > ei_traits
>> > for these things?
>>
>> Again, the enums aren't always present in the traits. See in MatrixBase.h.
>> Also, a "using" statement is probably simpler, since it doesn't define
>> anything new, so if we have the choice, it's probably better.
>
> Hmm, I see - yeah, it's not quite as straightforward as I hoped...
>