Re: [eigen] Qt's container support

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Alex Stapleton



2009/1/20 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Tue, Jan 20, 2009 at 12:46 PM, Alex Stapleton
> <alex.stapleton@xxxxxxxxxxxxx> wrote:
>> 2009/1/20 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>>> Hi all,
>>>
>>> I think that being able to store Eigen's matrices in Qt's containers
>>> is very important (especially QVector<>), and just like std::vector,
>>> there are a couple of issues:
>>
>>> Issue 2:
>>> the second problem is to enforce QVector to allocate aligned memory
>>> buffers. Fortunately, Qt's developers had the good idea to define
>>> wrapper functions around malloc/free/realloc called qMalloc, qFree
>>> etc.
>>> So the workaround is simply to redefine these functions to call
>>> ei_align_malloc. I added a Eigen/QtAlignedMalloc header which exactly
>>> does that (I'll commit it once the next issue will be solved).
>>> => PROBLEM SOLVED
>>
>> I am not a Qt person in general so please correct me if I am wrong but
>> wont this will result in *all* QVectors using aligned allocation?
>
> yes you are right, but I think that's harmless, several platforms
> already have an aligned malloc anyway...
>
> another possibility: since Qt is going to be LGPL, we can pick QVector
> implementation code to make a complete specialization of
> QVector<Eigen::Matrix>, and then we can elegantly fix all the three
> issues right away (and perhaps more, I have not checked all methods
> !). The obvious drawback is code duplication and so we'd have to watch
> the patches made to qvector.h which are very unlikely to happen
> anyway, so why not ?

I've just had a quick skim over the Qt source and it looks like this
will be quite difficult to implement as cleanly as the std::vector
one. QVector<T>::malloc is private for one and qMalloc isn't a
template function. One way around this might be

#undef QVECTOR_H
//#define stuff to trick QVector into working how we want
#include <QVector.h>
//#undef stuff we defined

but obviously that is straying into disgusting-hack territory and I am
not even sure it's possible to get it to work. The std::vector fix
requires specialisation of the allocators and a intermediary unaligned
Vector3f type which doesn't need aligned access so. Qt doesn't provide
nearly as general a container interface :(

This as you mention leaves the option of doing a full specialisation
of QVector<T> which personally I think is rather a lot of work,
although I suppose you could make it inherit from our std::vector
specialisation and add in the various extra bits of interface that
QVector supports.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/