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: lib.string.capacity test update
Date Wed, 31 May 2006 14:51:40 GMT
I corrected errors in 21.strings.h/.cpp and updated replace and cons
tests in the same way, now they exercise strings with special length
too.
The tests including modified yesterday are here (except cons):
http://people.apache.org/~antonp/stdcxx05312006a/

Are they ok to commit? (I keep in mind that capacity test should be
committed separately).

Martin Sebor wrote:
> Yes, we should for the UserAlloc specializations.
[...]
>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.

I started with cons test, here is my attempt to add verification of the
allocator methods usage:
http://people.apache.org/~antonp/stdcxx05312006b/
I think that we are needed in access to allocator methods names. I
modified the allocator header and implementation files to provide this
access,
but there may be another ways to do it.
What do you think about this?

Thanks,
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Wednesday, May 31, 2006 02:28
To: stdcxx-dev@incubator.apache.org
Subject: Re: lib.string.capacity test update


Anton Pevtsov wrote:
> The capacity test updated to last changes in the test driver is here
> (differences): http://people.apache.org/~antonp/stdcxx05302006/

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
functions):

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 
&tcase)
          : 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,
&arglen_)),

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

Martin

Mime
View raw message