stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: test for lib.string.cons
Date Tue, 16 May 2006 00:50:58 GMT
Anton Pevtsov wrote:
> Martin Sebor wrote:
>>Btw., it's beginning to look like we might run out of bits in the
> bitmap. If it happens we'll probably have to split it into two data
> members, one for the signature and one for the function id.
> Yes, we will run out of bits in the bitmap. The are next methods not
> added to the bitmap yet:
> begin(), end(), rbegin(), rend(), c_str(), data(), capacity(), size(),
> resize(), length(), max_size(), reserve(), empty(), clear() (the
> 21.string.capacity test has the old style), and all nonmembers
> (operators +, < , <=, >, >=, ==, !=).
> So it looks like we are needed two fields for function id and one for
> the signature id.

Okay, let me start looking into how best to add these.

> I plan to update the capacity test and write new one for iterators,
> c_str() and data.

I committed the user-defined allocator yesterday so that we can
get started on enhancing the tests to use it. Since I haven't
thoroughly tested UserAlloc yet let me do one test first to
iron out any kinks.

> Btw., there is a question abpout signatures: are we needed in special
> signatures for our allocator (i.e to have smth. like  (size_type,
> size_type) and (size_type, size_type, allocator) )?

Hmm, I guess so. Those are two different signatures that will
need to be exercised. The ctor test needs to verify that the
string object stores a copy of the allocator object it's
constructed with.

The other tests will need to verify that the class uses the
allocator object to allocate all storage and for any other
operations (i.e., uses and honors max_size(), uses address(),
construct(), destroy(), etc.). This will have to be done
conditionally only for UserAlloc (i.e., analogously to how
we test that Traits::eq() and Traits::length() are used).


View raw message