> you guessed right, the major issue avoiding such a construction is owing to
> the alignment of the data. Indeed, the vectorization of some fixed size
> vector/matrix types assume that the data are correctly aligned. So, in a
> general, you cannot avoid to generate 2 versions of SomeCoolFunction, one
> with the vectorization and one without (see below).
> In the very specific cases where the vectorization is disabled and/or you
> know the vector type won't be vectorized by Eigen or you know the data are
> aligned, then you can still simply cast your pointer:
> float result = SomeCoolFunction(*reinterpret_cast<Vector3f*>(inputdata),
> For instance, for Vector3f this is always ok because this type cannot be
> vectorized. (if we forget the use of reinterpret_cast which is not super
> A much more general solution is to template SomeCoolFunction and use static
> assertions to check the input types, eg:
> float SomeCoolFunction(MatrixBase<Derived>& v, void* somedata)
> // ...
> The advantage of this approach is that you can take as input any vector
> _expression_ like a sub vector of a matrix:
> SomeCoolFunction(mat33.col(1), bla);
> A drawback might be that the same code could be generated multiple time
> (though the compiler/linker are supposed to be able to factorize such
> redundancies automatically, but I don't really trust them for that).
> I agree that this solution is not optimal from a user perspective, but
> currently I cannot see any better solution to that issue.
> On Mon, Dec 8, 2008 at 12:06 PM, Benjamin Schindler
>> There is currently one thing which I really don't like atm in eigen. For
>> ease, I use a lot of direct vector's. But all the data I get from outside is
>> in the form of pointers, so I have to use maps. One thing I would really
>> love to have is a way to be able to do the following:
>> float SomeCoolFunction(Vector3f& v, void* somedata);
>> Map<Vector3f> input(inputdata);
>> float result = SomeCoolFunction(input, bla);
>> This is currently not possibel and I'm not sure what exactly is needed to
>> support this kind of stuff and in which way this would impact performance
>> (One can't assume alignment for example etc). But from a design perspective,
>> this would be just amazing :)
>> Any comments?