| Re: [eigen] Block sparse matrices and std vector compilation error |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
On 29.11.2014 10:13, Gael Guennebaud wrote:
On Wed, Nov 26, 2014 at 2:59 PM, Christoph Hertzberg <
chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
<DeveloperNotes>
We should probably add a constructor of Block<const X> from Block<X> to
make (*) work. OTOH, explicitly storing Block objects is not good style
anyways, IMO.
Defining Block objects locally is perfectly fine and sometimes help to make
the code clearer. In this case, it is recommended to either use auto or
Block ctor, that is:
auto b = a.block(...); // C++11
Block<MatrixXd> b(a, ...); // C++03
Thinking about it, at least for user code, I'd rather suggest this
alternative:
Ref<MatrixXd> b = a.block(...);
The advantage is that it works also if `a` is already a Block or a Map.
It does not work for sparse matrices, however (I opened a new bug for
that: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=910)
Using `auto` can cause hard-to-find troubles, if `a` itself is an
expression (in worst-case, depending on expressions which run out of
scope when `b` is used). Especially, with auto it is not clear to the
inexperienced user whether an actual object or some kind of expression
tree is stored (http://eigen.tuxfamily.org/bz/show_bug.cgi?id=825).
Doing:
Block<MatrixXd> b = a.block(...);
is error prone and should not be encouraged.
Storing Block objects within containers or as class attributes is indeed
more questionable.
Yes, the most important issue here is that problems arise at the time
operator= is used. Apparently, that does not happen during
container::push_back, but whether it happens at any other operation or
algorithm might be entirely implementation dependent.
Unfortunately, we can't disallow operator=(const Block<...>&), because
(for dense matrices) it would prohibit the perfectly legit use of
dest.block(...) = src.block(...);
For Block<SparseMatrix> we should probably make it more clear that it does
not have an assignment operator at all (implement an operator= which raises
a static assertion).
And for Block<*> it would be nice if we could tell the compiler that it is
not actually copy-assignable (I'm afraid, there is no easy way to tell this
without having C++-concepts (which did not even make it into C++11)).
Block is really like a reference. Perhaps it would help to make this
analogy clearer in the doc.
Do we have a recommended way to store views/blocks/... of a bigger
matrix into a container? Scenarios related to Hilario's use case might
be somewhat justifiable in some cases.
Christoph
--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen
Tel: +49 (421) 218-64252
----------------------------------------------