Re: [eigen] StdVector

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

2009/4/15 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> let's recall that the origin of the problem is a "mistake" in the STL
> standard where the prototype of std::vector::resize is:
>
>  void resize(size_t sz, T c);
>
> Actually, this issue is fixed in the C++0x standard where this
> function is defined as:
>
>  void resize(size_t sz, const T& c);

Right. So any good std::vector specialization will NOT be
c++98-standard compliant at least on this point.

Re-reading Markus's mail, he got linking errors, but that probably
wasn't on std::vector<Eigen::Something> because that would
consistently use our specialization, so his linking error was probably
on a std::vector<int> (or some other non-Eigen type).

In other words, if we can make sure that we only specialize
std::vector on Eigen types and leave it untouched for non-Eigen types,
I don't see how we can cause any linking errors, so redefining
resize() is harmless.

This is, I think, the main issue with the current StdVector : if I
understand it well, it redefines std::vector also for non-Eigen types,
thus causing linking errors with libraries unrelated to Eigen.

> Also note that in the gcc 3.x series this function was already defined
> as expected.

Interesting.

> About the previous solution, the problem is that was quite painful to
> write a specialization because you need to take care of the number of
> template arguments of the object class, and forward all ctors. So
> there is no way to do it with a simple macro.

Ah, right. Thanks for the refresher.

> Another proposal: enforce the user to write:
>
> std::vector<MyTrickyType,Eigen::aligned_allocator<MyTrickyType> > ....;
>
> with a specialization of std::vector for Eigen::aligned_allocator<> to
> workaround the resize() issue,

Ah, I like this one because it is homogeneous with other containers,
so the documentation would be especially short and consistent.

> and/or we provide a special container type:
>
> Eigen::aligned_vector<MyTrickyType> ....;

I prefer your previous idea :)

Cheers,
Benoit