> 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.

Me neither, I don't see any benefits (size and performance wise) using the bounded types.  Unless we are talking about some exotically specialised requirements I don't find they should be around. If the fixed containers are in I also believe that the new documentation should spend the least amount of lines on them as they are very confusing to the beginners. What do other people think?

> 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.

This is certainly a good option:
0. Deprecate c_vector and c_matrix for some time.
1. Copy their implementation into fixed_xxxx.
2. remove size member.
4. Merge Markus implementation in this implementation.
5. Reiterate the issues with size checking.

Markus what do you think?

Best
Nasos




> To: ublas@lists.boost.org
> From: jesseperla@gmail.com
> Date: Wed, 4 Aug 2010 12:04:57 +0000
> Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
>
> 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
>
>
>
> _______________________________________________
> ublas mailing list
> ublas@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: nasos_i@hotmail.com