Re: [eigen] Qt's container support

[ Thread Index | Date Index | More Archives ]

Since qt will become lgpl and community can engage:
Isn't the reason for the Q-Containers stl compatibility issues across Operating systems? If so, these issues should be gone by now. So if qt could use the stl containers that would reduce maintenance for trolltech and make it easier for eigen because you could use the existing std::vector wrapper. I know, this isn't something than can be easily done (and at least for qt4, they exist and eigen needs something to support them). But I'm thinking about the longterm solution

Gael Guennebaud wrote:
yes of course, but QVector's code is very unlikely to be modified.

Nevertheless we would still have to redefine qMalloc such that QVector
also works for the user classes which have to be aligned. The
specialization is really needed only for Eigen::Matrix where
operator=() is too limited on purpose.

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

Mail converted by MHonArc 2.6.19+