Boost logo

Ublas :

Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2010-08-04 08:04:57


Markus Grabner <grabner <at> icg.tugraz.at> writes:

> Do you also mean ublas::vector and ublas::bouded_vector by "all vectors"? I
> think there are enough use cases to justify those having a dynamic size (and
> hence the size_ member variable).

I think that bounded_vector is useful as a separate vector type where the
vector has stack allocated storage with a max, but otherwise is a resizable
vector. That said, when I was first coding I became very confused with the
names and ended up writing a lot of my code using bounded_vector when I should
have been using c_vector. This is part of my fear of having too many versions
of these types. To be honest though, I am not sure I will ever use the
bounded_vector in my code again.

> Modifying the behaviour of c_vector might result in existing code showing
> differnt runtime behaviour, which is very bad. Just removing the class will
> at least make sure that existing code can no longer be compiled (and
> silently misbehave), such that the developer is forced to consider
> alternatives, which is less bad IMO.

Fair enough (and to be honest I hate the name c_vector... as described above
I didn't figure out what it is until too late). But what kind of existing
code breaks would happen? Wouldn't it fulfill the same interface entirely?
One thing I can think of is boost::serialization...
But if we don't expect any interface changes, wouldn't it be nice for existing
code to be able to use the new c_vector features?

I assume that all of this applies to c_matrix as well and that c_vector is
just the starting point.

If the intent is to deprecate the existing c_vector and c_matrix implementation
and rename it if necessary, then that sounds great to me.

Thanks for working on this. It is an important feature.

-Jesse