Re: [eigen] Qt's container support

[Alex Stapleton <alex.stapleton@xxxxxxxxxxxxx>]

2009/1/20 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.

Ah so you did, however I disagree :) You will be caught in perpetual
forward and backward compatibility problems chasing Qt versions. Less
work right now maybe, but quite possibly rather messy in the future.

Since there is an unaligned variant of the classes which require
aligned access now users can store those in their QVectors and cast
them to the aligned references during themselves. To support that all
you have to do is make qMalloc aligned, which as you say is probably a
good compromise and almost certainly can be worked around using
optional macro hacks to QVector if it turns out to be an issue.

You could specialise QVector for the types which require alignment
such that it throws a compile time error as well.