[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] StdVector
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Wed, 15 Apr 2009 15:46:56 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cgZ+7tJCY/90NDWg4xNlYafs0h07sf3uMiJd0m9uERg=; b=qCGMrWPsbItzyCVEB0Mi8JhE3GMev4xxxJX3X/IXyVo9Djw/3WmkTBp5cRrXcnecLx W0i2Dzp0oGdBvzH3Nyq30CcXc4ITPrwkhmNCMFuW9sjUmY4D0zk4KQ/JRrbfwyX+X3UU YwMgTYcb5FMFe6Dc65sLWA/Xre1IZt6liAxfM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=nnAnuzeHg/Gcu0zPT1mQZTEYGjUuw25nIDOq0bM5utctlauv75t+91P/DkuQ8C1PNM bfqOsSIQhE0xENymua5CeT/BjkCdnt6q4J0Et1fRc4NgidMgG2Sx6Nu0LwKRa09Fhj7W u67lC8dDFMDIJRsGroOktoVKhggSoIlH8nRUM=
2009/4/15 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> let's recall that the origin of the problem is a "mistake" in the STL
> standard where the prototype of std::vector::resize is:
> void resize(size_t sz, T c);
> Actually, this issue is fixed in the C++0x standard where this
> function is defined as:
> void resize(size_t sz, const T& c);
Right. So any good std::vector specialization will NOT be
c++98-standard compliant at least on this point.
Re-reading Markus's mail, he got linking errors, but that probably
wasn't on std::vector<Eigen::Something> because that would
consistently use our specialization, so his linking error was probably
on a std::vector<int> (or some other non-Eigen type).
In other words, if we can make sure that we only specialize
std::vector on Eigen types and leave it untouched for non-Eigen types,
I don't see how we can cause any linking errors, so redefining
resize() is harmless.
This is, I think, the main issue with the current StdVector : if I
understand it well, it redefines std::vector also for non-Eigen types,
thus causing linking errors with libraries unrelated to Eigen.
> Also note that in the gcc 3.x series this function was already defined
> as expected.
> About the previous solution, the problem is that was quite painful to
> write a specialization because you need to take care of the number of
> template arguments of the object class, and forward all ctors. So
> there is no way to do it with a simple macro.
Ah, right. Thanks for the refresher.
> Another proposal: enforce the user to write:
> std::vector<MyTrickyType,Eigen::aligned_allocator<MyTrickyType> > ....;
> with a specialization of std::vector for Eigen::aligned_allocator<> to
> workaround the resize() issue,
Ah, I like this one because it is homogeneous with other containers,
so the documentation would be especially short and consistent.
> and/or we provide a special container type:
> Eigen::aligned_vector<MyTrickyType> ....;
I prefer your previous idea :)