Boost logo

Ublas :

From: Shawn D. Pautz (sdpautz_at_[hidden])
Date: 2005-09-28 15:49:03


Here's another concept conformance issue, although it's possible that
it's a compiler issue. According to the documentation for the Vector
concept a call to resize with a preserve value of false should yield a
vector "in the same state as that after an equivalent sizing
constructor". This does not appear to be the case, at least for
ublas::vector and bounded_vector, if "same state" means "same values".
The following code does not generally yield equivalent vectors for me:

const size_t N = 10;
ublas::vector<double> ublasSizeVec(N);
ublas::vector<double> ublasResizeVec;
ublasResizeVec.resize(N, false);
// ublasSizeVec == ublasResizeVec ???

In both cases it appears that the contents are random bits, and hence
equivalence cannot be guaranteed. Are the contents supposed to be
zeroes, or at least value_type(), in both cases? I'm using gcc 3.2.3.

Shawn

Michael Stevens wrote:

>On Wednesday 28 Sep 2005 17:47, Shawn D. Pautz wrote:
>
>
>>Class ublas::vector (and perhaps others) seems to be missing the
>>max_size() member function. According to the online documentation
>>vector is a model of Vector, which is a refinement of
>>RandomAccessContainer, which requires that member function. I'm using
>>Boost 1.33.0, but it appears that the CVS version also is missing that
>>member. Is there a bug here or is the documentation in error?
>>
>>
>
>Both! The definition of Vector as a refinement of RandomAccessContainer was
>done quite recently. It was added when I merged the work Toon did on
>integrating the documention with STL Concepts. I think last year we discussed
>how we wanted to define the Vector Concept and RandomAccessContainer was
>chosen.
>
>Looks like a few member functions slipped through the net and we never
>considered that they would need implementing. Looking at the definition of
>STL Container it looks like we will need 'empty' and 'max_size'. I recall the
>'max_size' is subject to a defect report in the standard as it is not really
>clear what it should return. I would be good to check on the status of this.
>
>Anyone fancy submitting a patch!
>
>Michael
>
>

-- 
Shawn D. Pautz
Simulation Technology Research, MS 1179
Sandia National Laboratories
P.O. Box 5800
Albuquerque, NM 87185
Phone: 505-284-4291
Fax: 505-844-0092
E-Mail: sdpautz_at_[hidden]