From: Michael Stevens (m-stevens_at_[hidden])
Date: 2005-01-22 12:06:26
On Friday 21 January 2005 20:10, Toon Knapen wrote:
> Ralf Denzer wrote:
> > Hi Michael,
> >
> >> Does that fix you problem?
> >
> > Unfortunately, no.
I asked because the sematics have changed from Boost_1_32_0 and the current
development version which is based on uBLAS_pure. In uBLAS_pure this is not
supposed to work! Then the correct solution as Gunter suggested is to make
the object be constructable from zero.
> patched. Actually the resize zero-initialised the new elements. This
> does not work of course for value_type's that have no constructor that
> takes an int.
Toon,
I think is incorrect for the current development HEAD. It should be committed
only to the Boost_1_32_0 branch were the value_type() semantics are specified
in documentation for resize. Even then such ad-hoc patching is not good.
There are several more locations in vector.hpp the should be fixed for
consistency! If I get some time I see I can come up with a consistent patch.
uBLAS_pure specificly made the distinction by requiring elements be
constructible from zero. This also means that the hundred or so location in
uBLAS where this is required are easy to find! I think at the uBLAS meeting
we discussed more user friendly solutions but they require consistent
application and detail thought about the semantics.
Personally I think the zero construable requirement has the advantage that it
is simple and requires no template magic external to the class type. Also
specifying element requirements and semantics that are consistent and
efficient for both dense and sparse containers is not easy!
Hopefully this argument makes sense. Can we revert the patch to HEAD and apply
it to the Branch? Please!
Michael
--
___________________________________
Michael Stevens Systems Engineering
Navigation Systems, Estimation and
Bayesian Filtering
http://bayesclasses.sf.net
___________________________________