> As I said in my previous message, fixed_vector was an easy exercise. 
> However, a fixed_matrix is much more complicated since ublas::matrix already 
> includes members "size1_" and "size2_" to define the matrix size. I don't 
> know of any method to "get rid of" these members in a derived class (such 
> that - again - a contiguous array of matrix coefficients can be cast to an 
> array of fixed_matrix). Instead I experimented with the following approac...

I think I had some reasoning in the past against the appropriateness of  using matrix_container to derive the fixed_matrix. As I am thinking it again I cannot find a reason anymore. Do you think the fixed_matrix (and maybe the fixed_vector) can be derived from those? Everything should be working, as uBlas is designed to work on expressions (containers are expressions) rather than matrices and vectors.

> ...  Instead I experimented with the following approach: ....

Your suggestions will also work, but doing such a radical change looks terrifying to me from backwards compatibility assurance perspective. Doing that will probably require some serious dedication to make sure things are working.

 

Very Best,

Nasos

 

> To: ublas@lists.boost.org
> From: grabner@icg.tugraz.at
> Date: Mon, 2 Aug 2010 20:02:19 +0200
> Subject: Re: [ublas] fixed size vector in boost::numeric::ublas?
>
> Nasos Iliopoulos wrote:
>
> > Furthermore in order for this addition to be complete, fixed_vector and
> > fixed_matrix classes should be implemented, that would be similar to
> > bounded_vector and bounded_matrix (without the size member variables).
> As I said in my previous message, fixed_vector was an easy exercise.
> However, a fixed_matrix is much more complicated since ublas::matrix already
> includes members "size1_" and "size2_" to define the matrix size. I don't
> know of any method to "get rid of" these members in a derived class (such
> that - again - a contiguous array of matrix coefficients can be cast to an
> array of fixed_matrix). Instead I experimented with the following approach:
>
> 1.) rename ublas::matrix to ublas::matrix_base
>
> 2.) add an additional template parameter "S" to ublas::matrix_base which is
> a class having methods "size1()" and "size2()" and from which
> ublas::matrix_base is derived, i.e., the declaration looks like this:
>
> template<class T, class L, class A, class S >
> class matrix_base:
> public matrix_container<matrix_base<T, L, A, S> >, public S {
> ...
>
> 3.) create two classes "matrix_size_dynamic" and "matrix_size_static" which
> can be used as template parameter "S" in ublas::matrix_base. The size*()
> members of matrix_size_dynamic return the values of corresponding members
> storing the current size of the matrix at runtime, the size*() members of
> matrix_size_static return the fixed size of the matrix given as template
> arguments at compile time.
>
> 4.) create a new ublas::matrix derived from ublas::matrix_base like this:
>
> template<class T, class L, class A>
> class matrix:
> public matrix_base<T, L, A, matrix_size_dynamic> {
> ...
>
> While this worked well for some simple examples, I'm not sure whether it
> would break existing code when expression templates are involved. Before I
> dig deeper into this, I'd like to ask for comments about such an approach
> (or if it can be done in a totally different way).
>
> Kind regards,
> Markus
>
>
> --
> Markus Grabner
> Institute for Computer Graphics and Vision
> Graz University of Technology, Inffeldgasse 16a/II, 8010 Graz, Austria
> WWW: http://www.icg.tugraz.at/Members/grabner
>
> _______________________________________________
> ublas mailing list
> ublas@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: nasos_i@hotmail.com