| Re: [eigen] Qt's container support |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Qt's container support
- From: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 20 Jan 2009 16:55:07 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=W0kR/HHRjImCIklf3E1lENEur1GmRIFwzVpa2jaClq8=; b=sT4MRpvKsJCK4D1Dd/sksRYLIDLzdW0g6abRa6IIFhAAUItsqyn9Z8GgHCb1jGVxHv An8ReHqQHPqqaGUZxLPrmvqXFZQqNbFhCWScr4vaYiDbOcYko/RG+TDsygifOv6nkODx I/y49Kf5D3SRnENvTgUfvo6beF1xwfoa4J6ko=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sN1++T4jvQMHFDU3/tOf9VikJ4Z+VNZYVDOpcAEjs1hLDTDhg6OEbBBlInzFuDQPJF Su6hqj0+Hqb2hIwgvqYC78Q/6i9gHFdKZs/bb2YsdczzYb1L1lEzVRkSKB5vhTE+ydmh kaSVgSEAoywl9sJb5bxFjawnJYzyduHy+45J8=
2009/1/20 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> Issue3:
> The last issue I found is with QVector::fill(const T&,size_t) which is
> the equivalent of std::vector<T>::resize(size_t,T). Here the argument
> is passed by reference so no alignment issue. The problem is the use
> of the default ctor and operator= to initialize/copy the new elements
> while our operator= does not allow to set an uninitialized matrix.
Notice that this issue 3 only affects dynamic-size Eigen objects.
Most of the times a user will want to use a Qt container, that will be
on a fixed-size object, like QVector<Eigen::Vector2d>.
So if all else fails, it seems acceptable to me to say that
QVector<Eigen::VectorXd> doesn't work.
Reason why statistically this will almost never be a problem:
* Qt containers are typically used in close-to-GUI stuff
* dynamic-size Eigen objects are typically used in heavy backend stuff
So i think that most users will find it OK to be told to use std::
containers instead in this case.
Benoit