Re: [eigen] Qt's container support

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

On Tue, Jan 20, 2009 at 1:21 PM, Alex Stapleton
<alex.stapleton@xxxxxxxxxxxxx> wrote:
>> 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.


Note that I suggested to simply copy/paste qvector.h code and make the
few modifications we have to do, that's very little work, and that's
probably the safest solution.

Gael