Re: [eigen] Std Vector again

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

2009/6/26 Rene Wagner <rw@xxxxxxxxxxxx>:
> On Fri, 2009-06-26 at 14:55 +0200, Benoit Jacob wrote:
>> Whence the StdVector header. In Eigen 2.0.3, it
>> takes care of specifying the allocator for you. (Not in the
>> development branch though).
>
> Pardon my ignorance, I haven't been able to follow the mailing list as
> closely as I would have liked to recently... What's the current state of
> affairs in the development branch?

In the development branch, we decided that we shouldn't fiddle with
std::vector<T> unless T is an Eigen type.
So we decided that a good way to make sure that we're not altering
std::vector more than we should, is to only change std::vector when it
is used with Eigen::aligned_allocator.

> Keir raises a point that is also important to me: Does the current approach
> play nice with templated types that go into a std::vector?

I don't see any reason why there should be a specific problem with
templated types...?

>> > Then I tried switching to using the eigen specialization in Eigen/StdVector.
>> > That ended up being worse, because suddenly my header files had to be
>> > included in a certain order, or there would be mysterious runtime breakage.
>>
>> The only requirement should be: include <Eigen/StdVector> before
>> including <vector>. Actually, <Eigen/StdVector> takes care of
>> including <vector> for you. all you have to do is replace <vector> by
>> <Eigen/StdVector>.
>
> I'm afraid it's not that simple. First of all, as a library author, I
> don't have control over how users of my code include my headers.

OK, indeed, if you're a library author AND you have to exposes these
vector<> types as part of your public API, then you're forced to pass
that requirement to your users.

> Secondly, even if you could somehow ensure that <Eigen/StdVector> is
> always included first code that declares std::vector in an STL
> compatible way still triggers errors like the following:
>
>
> In file included from /usr/include/boost/functional/hash/hash.hpp:16,
>                 from /usr/include/boost/functional/hash.hpp:10,
>                 from /usr/include/boost/asio/detail/hash_map.hpp:24,
>
> from /usr/include/boost/asio/detail/epoll_reactor.hpp:37,
>                 from /usr/include/boost/asio/impl/io_service.ipp:25,
>                 from /usr/include/boost/asio/io_service.hpp:550,
>                 from /usr/include/boost/asio/basic_io_object.hpp:20,
>                 from /usr/include/boost/asio/basic_socket..hpp:24,
>
> from /usr/include/boost/asio/basic_datagram_socket.hpp:25,
>                 from /usr/include/boost/asio.hpp:20,
>
>                 /usr/include/boost/detail/container_fwd.hpp:80: error:
> redeclared with 2 template parameter(s)
> /usr/include/eigen2/Eigen/StdVector:88: note: previous declaration
> ‘template<class T, class AllocT, bool HasAlignedNew> class std::vector’
> used 3 template parameter(s)
>
> The offending code is:
>
> // ...
>
> // gcc 3.4 and greater
> namespace std
> {
> // ...
>    template <class T, class Allocator> class vector;
> // ...
> }

Hmm I think that's precisely the problem that's solved by the
development version (as opposed to 2.0.3) since there we don't modify
std::vector unless used with Eigen::aligned_allocator.

>> This flaw is being addressed in C++0x by the way.
>
> Let's be realistic here. It's clearly going to be C++1x, and it will
> probably take another few years until implementations are ready for
> prime time.

I know, i was just saying that to insist that it's a well-known
problem with std::vector, it's not specific to Eigen.

>> > What about having an Eigen::vector<> class?
>
> I'd like to second that request. Having a standard (as in "standard for
> code that uses eigen2") vector replacement which uses std::vector
> internally but doesn't require any workarounds would be a huge
> improvement over the current situation IMO.

Yes, i just chatted about that with Keir, it seems useful to have a
Eigen::vector alongside the current StdVector solution. Both address
different use cases, they are complementary. Indeed in the case of a
library with vector's in its public API, Eigen::vector would be
better. So we could have both solutions in separate, independent
headers.

> On a related note, EIGEN_DONT_VECTORIZE didn't work for me with 2.0.1
> but appears to work with 2.0.3 (although I can't be sure that isn't due
> to other changes in my code).

EIGEN_DONT_VECTORIZE is not related to this topic, because Eigen has
the same alignment behavior (and requirements) regardless of whether
vectorization is enabled. This is in order to ensure ABI
compatibility, so that it's possible to link vectorized and
non-vectorized code.

What you want here is EIGEN_DONT_ALIGN but this option is only
available in the development version.

In Eigen 2.0.3, to disable alignment, you'll have to edit
Eigen/src/Core/util/Macros.h and at line 44 replace

#if !defined(__GNUC__) || defined(__i386__) || defined(__x86_64__) ||
defined(__ppc__) || defined(__ia64__)

by

#if 0

Cheers,
Benoit


>
> Cheers,
>
> Rene
>
>
>
>