Re: [ublas] max_size in vector?

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: [phone]
Fax: [phone]
E-Mail: sdpautz_at_[hidden]