Hello all,
I am playing a bit with bounded_vector's under the hood structure and found a bit of a strange behaviour.

#define NDEBUG

#include <boost/numeric/ublas/vector.hpp>

#include <boost/numeric/ublas/io.hpp>

namespace ublas = boost::numeric:ublas;

int main() {

ublas::bounded_vector<double,2> a;

ublas::vector<double> b(4);

b(0)=1.0; b(1)=2.0; b(2)=0.0; b(3)=0.1;

a(0)=33.0; a(1)=44.0;

std::cout << a.size() << std::endl;

std::cout << a << std::endl;

a=b;

std::cout << a.size() << std::endl;

std::cout << a << std::endl;

return 0;
}

output:

[2](33,44)

[4](1,2,0,0.1)

if I don't use NDEBUG I get an assertion about the size of the vectors in the assignment.
On the other hand when using NDEBUG I understand that not checking for the bounded_vector at run time may be a design choice so that it makes bounded_vector a bit faster when assigning to another type, but correctness here may be a bit important (for example by throwing an exception at run-time).

I am developing fixed_storage and fixed_vector types, and I would like your opinion on how the same assignment could be implemented. Should the resize(..) check for compatible sizes in release mode or not (in which case it can easily cause a segmentation fault, or even write at memory locations not in the container of fixed_storage)? Maybe the debug-time assertion is enough (as in the case of bounded_vector) for most people.

Thanks in advance
Nasos Iliopoulos

Windows Live: Make it easier for your friends to see what you�re up to on Facebook. Find out more.