Re: [eigen] Feature request - Prevent dynamic resizing of a matrix

[ Thread Index | Date Index | More Archives ]

On Wed, Jan 28, 2009 at 5:45 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> OK, this has been a tough decision. Let's recall the arguments on both sides.
> In favor of automatic resizing:
> 1) This is more practical for the majority
> 2) This is the usual behavior of objects in C++ and in the C++ STL
> 3) Because this is what STL containers assume, it's almost required in
> order to allow convenient usage of STL containers with Eigen types
> Against automatic resizing:
> 1) Exactly what you say. Indeed automatic resizing can hide nasty bugs.
> So the default behavior will stay as it is right now, but what you
> propose, with a #define, sounds like a good solution to me. I
> implement it now. I'd rather call it EIGEN_NO_AUTOMATIC_RESIZING
> because i think we still want to allow explicitly calling resize().
> Notice that one could also consider implementing this behavior as a
> matrix type option. So you would do
> typedef Eigen::Matrix<float, Eigen::Dynamic, Eigen::Dynamic,
> Eigen::NonResizable> MyMat;
> and then objects of type MyMat have this behavior. Stuff to consider for 2.1...

This seems like the best way to me, defaulting to Eigen::Resizeable.
Having #define's like this is usually a bad idea, because then someone
reading the code has to know whether or not that define is set. By
allowing both, the code is more flexible and easier to read. Does
adding more template parameters like this adversely affect compilation


> Cheers,
> Benoit
> 2009/1/28 Timothy Hunter <tjhunter@xxxxxxxxxxxx>:
>> Hello all,
>> I has been decided that the operator=(A,B) would resize A if it does
>> not fit the size of B, right?
>> I had a bug in my code I had problems to detect because of this
>> feature. It would be nice to have an assert that fails if the matrices
>> are of different size, and let the user decide to use this assert with
>> some flag definitions like EIGEN_DO_NOT_RESIZE_DYNAMIC_MATRICES.
>> Is it possible to do it with the current code?
>> -- Timothy Hunter

Mail converted by MHonArc 2.6.19+