incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <Ant...@moscow.vdiweb.com>
Subject RE: test for lib.string.cons
Date Tue, 16 May 2006 15:55:32 GMT
Martin Sebor wrote:
> 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.

I tried to use the UserAlloc to enhance the cons test. It required
changes in 21.strings.cpp - I wrote a two new macros:

#define DEFINE_TEST_DISPATCH_ALLOC(fname)
\
    static void
\
    fname (const MemFun &memfun, const TestCase &tcase) {
\
        if (StringMembers::UserAllocator == memfun.alloc_id_) {
\
            TEST_DISPATCH_ALLOC (UserAlloc, fname, memfun, tcase);    \
        }
\
        else {
\
            TEST_DISPATCH_ALLOC (std::allocator, fname, memfun, tcase);
\
        }
\
    } typedef void rw_unused_typedef

and TEST_DISPATCH_ALLOC to call fname with allocator. 

The test was successfully passed.

Martin Sebor wrote:
> 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).

Ok, I'll verify this.


Thanks,
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Tuesday, May 16, 2006 04:51
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string.cons


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).

Martin

Mime
View raw message