[eigen] Re: State of the problem with std::vector

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

So, another possible solution... is to make a specialization
std::vector<Vector4f> that inherits what it would normally be, and
redefines resize().
In order to avoid ambiguity, we would then define the two forms of
resize(), without default arguments.
The problem is then that if another method of the base std::vector
class calls resize, it'll call the one from the base class.
Fortunately, with GCC's implementation no other method of std::vector
calls resize. But things seem to be different with MSVC.
Still, we would reimplement them if there aren't too many. So if you
have MSVC and like this possible solution please tell us what other
methods of std::vector call resize...
Cheers,
Benoit

2009/1/8 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> Hi,
>
> THE PROBLEM
>
> (as discussed since yesterday on IRC)
>
> std::vector<value_type> (both GCC and MSVC implementations) has a
> resize() method that takes a value_type by value.
>
> Since attributes don't work on function parameters (with GCC and
> MSVC), this means that this program,
>
> #include <Eigen/Core>
> #include <vector>
>
> int main()
> {
>  std::vector <Eigen::Vector4f> v(10);
>  v.resize(20);
> }
>
> triggers the unaligned-array-assert (unless of course by pure chance
> (50%) the copied vector happens to be aligned).
> If we disabled the asserts, it will crash when trying to use aligned
> SSE insns on this unaligned location.
>
> THE ONLY POSSIBLE SOLUTION WE CAN SEE
> thanks a lot to "alexs" from ##c++ IRC channel...
>
> [18:09] <bjacob> ggael: so i got help on ##c++
> [18:09] <bjacob> the only idea that seems to have a chance of working,
> [18:09] <bjacob> is to define a separate vector type inheriting Vector4f,
> [18:10] <bjacob> this vector type has a copy constructor that doesn't
> use SSE insns
> [18:10] <bjacob> and a default constructor that doesn't do the
> unaligned array assert
> [18:10] <bjacob> and use inheritance and implicit conversions to let
> the user use std::vector on that vector type
> [18:11] <bjacob> while using it as std::vector<Vector4f>
> [18:13] <bjacob> so could make this templated .... template<typename
> MatrixType> class AllowUnaligned : public MatrixType;
> [18:13] <bjacob> std::vector <  AllowUnaligned <Vector4f> >
> [18:14] <ggael> ok, I see
> [18:17] --> alexs_ a rejoint ce canal (n=alexs@unaffiliated/alexs).
> [18:17] <alexs_> Looks interesting :)
> [18:19] <bjacob> ok some backlog pasting....
> [18:19] <bjacob> http://rafb.net/p/C27reW66.html
> [18:20] <bjacob> alexs_: ^
> [18:20] <alexs_> yeah :)
> [18:20] <bjacob> ggael: http://rafb.net/p/TDr0X549.html
> [18:25] <alexs_> You could probably use a specialisation of
> vector<Vector4> that statically sets the value_type to the right
> thing, to hide it from the user?
> [18:29] <bjacob> hm. and by the way set an aligned allocator. good idea.
> [18:30] <bjacob> this will mean inheriting from std::vector, never
> tried, hope it's easy (don't know what's the best way to preserve the
> ctors, assignment operators, etc, that don't get inherited)
> [18:30] <alexs_> composition should work ok
> [18:30] <alexs_> it's not too many things :)
> [18:31] <alexs_> operators are not members of vector anyway
> [18:31] <bjacob> you'd recommend composition (i guess this means
> having-as-a-member) over inheritance?
> [18:31] <bjacob> not even assignment operators?
> [18:31] <alexs_> composition for the things that inheritance doesnt bring in
> [18:32] <bjacob> oh, i see
> [18:46] <bjacob> alexs_: by the way it is not just MSVC that doesn't
> allow align attribute on function parameters
> [18:46] <bjacob> here, gcc 4.3.2 allows this code to compile but the
> attribute isn't honored and i get my assertion at runtime saying the
> object is unaligned
> [18:48] <alexs_> bjacob: Oh :(
> [18:49] <alexs_> is it a function parameter if you want aligned arguments?
> [18:49] <alexs_>     -mpreferred-stack-boundary=num
> [18:50] <bjacob> hm good idea
> [18:50] <alexs_> default is 16 bytes
> [18:50] <bjacob> oh -- so it's not what we want then -- as 16 bytes should be OK
> [18:51] <alexs_> Unless you use -Os
> [18:51] <bjacob> ++ -mpreferred-stack-boundary=16 -I
> kde/kdesupport/eigen2/ a.cpp -o a && ./a
> [18:51] <bjacob> a.cpp:1: error: -mpreferred-stack-boundary=16 is not
> between 2 and 12
> [18:51] <alexs_> Yeah, it is raised to a power of 2
> [18:51] <bjacob> oops, "++" should be "g++"
> [18:51] <alexs_> you want 4 :)
> [18:51] <bjacob> ah ok
> [18:51] <alexs_> but my man page says that is the default
> [18:51] <bjacob> yes and with 4 is still get the same problem
> [18:52] <bjacob> "preferred" is probably not strictly honored
> [18:52] <alexs_> So it's not aligning them...
> [18:52] <alexs_> It does say "attempt"
>
> Cheers,
> Benoit
>

---