Re: [eigen] about std::vector::resize (again)

[ Thread Index | Date Index | More Archives ]

2009/2/6 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> std::vector<A,aligned_allocator> will fail because of bugged
> vector<T>::resize(size_t,T). Our current solution is OK for Eigen's
> types for which we workaround via several tricks. However this
> solution is not extensible to user types (have to add special
> constructor to discard the assertion, the specializations of
> std::vector cannot be automatically generated by a macro, etc..).

OK, I hadn't thought of that, makes sense.

> So here is what I propose: let's be ugly !
> #if define(_GLIBCXX_VECTOR) || define(_VECTOR_)
> #error you must include Eigen/StdVector before std::vector
> #endif

ouch. I wanted to avoid that, but indeed it seems that we have no choice...

> yes I know this a bit ugly, but I don't know better solution to tackle
> this issue once for all. Of course this is just a starting point. If
> that really works, the next step is to have a specialization of
> std::vector for classes having EIGEN_MAKE_ALIGNED_OPERATOR_NEW (this
> is easy to detect), and do the workaround + "aligned_allocator as
> default" only in this specialization.
> I'll test it with MSVC tonight, and let you know.

Looking forward to see this working! I wonder how you'll detect
EIGEN_MAKE_ALIGNED_OPERATOR_NEW in a way that still compiles for
classes not having this macro?


Mail converted by MHonArc 2.6.19+