stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: lib.string.capacity test update
Date Tue, 30 May 2006 22:28:08 GMT
Anton Pevtsov wrote:
> The capacity test updated to last changes in the test driver is here
> (differences):

This looks good. Since the changes to the capacity test are more
involved than just adding new test cases could you please commit
them separately from all the others (it should be checked in at
the same time or after the changes to the driver to make sure
things at that revision still work).

> Also there are required changes to the 21.string.h/.cpp files.

In 21.strings.cpp we allow for at most 32 enable/disable options
corresponding to the number of distinct overloads of functions
(members or not) exercised by the test. The specific options are
computed from the StringTest array passed to rw_run_string_test.
The hunk below is incorrect (more than 32 options) and should be
unnecessary (there should be no test that exercises more than 32

Index: 21.strings.cpp
--- 21.strings.cpp	(revision 410297)
@@ -1365,6 +1384,38 @@
                   _rw_opt_func + 29,
                   _rw_opt_func + 30,
                   _rw_opt_func + 31,
+                 _rw_opt_func + 32,
+                 _rw_opt_func + 33,
+                 _rw_opt_func + 34,
+                 _rw_opt_func + 63,

Also, the whitespace change to 21.strings.h below seems
unnecessary (all it does is add some trailing whitespace):

Index: 21.strings.h
--- 21.strings.h	(revision 410296)
+++ 21.strings.h	(working copy)

@@ -659,9 +703,10 @@
      StringTestCaseData (const StringFunc &func, const StringTestCase 
          : strlen_ (BUFSIZE), arglen_ (BUFSIZE), reslen_ (BUFSIZE),
            str_ (rw_expand (str_buf_, tcase.str, tcase.str_len, &strlen_)),
-          arg_ (rw_expand (arg_buf_, tcase.arg, tcase.arg_len, &arglen_)),
+          arg_ (rw_expand (arg_buf_, tcase.arg, tcase.arg_len, 

> Here is a question: shall we check that testing methods use the
> underlaying allocator methods?

Yes, we should for the UserAlloc specializations. It will be
a little tricky because the standard doesn't specify when or
how many times they should be used (e.g., address()). In the
case of construct() or destroy() we can check that the functions
are called at least as many times as there are elements being
constructed or destroyed (or that the difference of the numbers
of calls to the two functions is the same as the number of
elements constructed or destroyed but without a user-defined
ctor in the character class it's impossible to tell that the
construction or destruction of some [other] elements doesn't
bypass the functions. If you plan on working on this I suggest
doing just one test and posting it for review so that you don't
have to make changes across the board if problems are discovered
or if we decide to make improvements.


View raw message