Subject: Re: [ublas] bounded_vector behaviour
From: Gunter Winkler (guwi17_at_[hidden])
Date: 2009-09-07 16:22:14
Nasos Iliopoulos schrieb:
> Hello all,
> ublas::bounded_vector<double,2> a;
> ublas::vector<double> b(4);
> 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).
This is raises the very old discussion about mandatory bounds checks. If
you had asked me a few years ago then I answered "performance over
safety". Right now I always prefer safety over performance. The only
place where the bounds check really hurts is operator()(int) and
operator(int). Any other place should also do bounds checks in release
> 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.
I'd use the following strategy: Have three macros for consistency checks.
MANDATORY_CHECK ... will always be executed
OPTIONAL_CHECK ... will be executed by default
DEBUG_CHECK ... will only be executed in debug mode
and maybe another one for expensive checks like the
BOOST_UBLAS_TYPE_CHECK which checks the structure of the resulting
matrix and vector by doing the computation a second time with dense
types that are know to work well. The macro definition itself should be
configurable to either throw an exception or simply abort (if exceptions
are disabled for what ever reason.) Please have a look at