|
|
Ublas : |
From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-04-12 09:20:31
Hi Michael,
On Sunday 13 February 2005 14:21, Michael Stevens wrote:
> Hi Karl,
>
> On Friday 11 February 2005 11:35, Karl Meerbergen wrote:
> > Michael Stevens wrote:
> > >I am a bit confused regarding the new 'remove_const' logic in
> > > "triangular" however. I have a couple of questions regarding this.
> > >a) Why is it necessary? I don't see how the 'const'ness of M can
> > > prorogate into _temporary_type.
> > >If is is necessary
> > >b) Is it only necessary for traingular_adaptors?
> > >c) Should it not go into "temporary.hpp"
> >
> > The remove_const is required when M is a const type. For const types the
> > temporary_traits are not defined.
>
> Do you have a specific example of when you see such behaviour? After
> thinking about the code and try a test case I don't believe this to be the
> case. The following simple test case illustrates what I am thinking about
> typedef matrix<float> matrix_type ;
> matrix_type h( 1, 1 );
> matrix_temporary_traits<symmetric_adaptor<const matrix_type, upper>
> >::type tsa;
> tsa(0,0) = 1;
> This compiles fine even though symmetric_adaptor does not have remove_const
> code. Why this is follows from the following cascade of definitions:
>
> matrix_temporary_traits<symmetric_adaptor<const matrix_type, upper> >::type
>
> := matrix_temporary_traits< const matrix_type > ::type
> := const!matrix_type::matrix_temporary_type
> := const!matrix_type::self_type
> := matrix<T, L, A>
>
> I use the notation const!matrix_type to represent the type that matches
> <const matrix_type>. This type is in fact matrix_type, although the
> distinction does not effect the rest of the analysis. The last step is
> critical as a Containers self_type should never be const.
>
> Michael
I see. Perhaps I was too fast with this. I do not recall the reason why I did
this. I removed the remove_const and compiled our code sucessfully. If any
problem would arise in the future, I let you know.
Karl