incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: lib.string.capacity test update
Date Thu, 01 Jun 2006 23:36:48 GMT
Anton Pevtsov wrote:
> Martin Sebor wrote:
> 
>>As a general comment, we should be on the lookout for ways to reduce
> 
> the amount of boilerplate code that will end up repeated across all
> tests, such the snippet of code below. It would be      > nice to be
> able to say something like:
> [...]
> 
> As a first step of this process I added new structure to keep
> information about testing SharedAlloc method, the criteria and value
> using to compare the number of calls. 
> I.e this structure tells something like "<some_method> should be called
> <criteria: at least, no more than, exactly, etc> n times".
> The changes I made to rw_allocator.h, allocator.cpp and
> 21.string.cons.cpp are here:
> http://people.apache.org/~antonp/stdcxx06012006/

I spent today looking at this and trying some changes. I still
think it's a good approach in principle but I'm finding out that
containers in general and strings in particular don't seem to be
required to use any allocator functions other than allocate and
deallocate. That makes the tests not just difficult to write
with any accuracy but also rather pointless. I posted a question
to the committee's mailing list to see what the intent is (it's
possible that the requirement is intended but missing).

> 
> I think that on next steps of simplification we may bind this new
> structure with method overload id (there is a dependency between
> information stored in the structure and this id) and
> as a result verify the allocator usage in the same way as we done with
> "usual" test cases.
> What do you think about this?

Until the question of exactly what is required is resolved I think
it will be best to put this on hold and finish the rest of the string
tests. If it turns out that the only allocator members that are
required to be called really are allocate and deallocate it will
simplify the checking quite a bit.

Btw., I'm not sure exactly what other string tests are left but an
enhancement that still needs to be implemented across several of the
tests (ctors, append, erase, insert and replace) is exercising the
exception safety of the member function templates. Since much of the
exception safety code in the range test functions will be the same
as the code in the functions testing the ordinary (non-template)
overloads it would be good to share it to avoid bloat and reduce
maintenance effort.

Martin

Mime
View raw message