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: Re: test for 21.strings.capacity
Date Mon, 06 Mar 2006 16:21:10 GMT
The attached file contains the updated version of the test for
21.string.capacity.
I modified the code and pass the tested string length to the widen
function and basic_string ctor to avoid the bug with strings containing
embedded NULs.
But I suspect a bug in the rw_assert formatting output for {#*S}.
The wchar string "abc" is displayed as "a\0b" (maybe the function
dumps each byte, not symbol here).

Btw., maybe it would be useful to move the widen function to rw_char
header (or some another place in the test driver).


With best wishes,
Anton Pevtsov


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com]
Sent: Sunday, March 05, 2006 01:07
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for 21.strings.capacity


Anton Pevtsov wrote:

 >> The attached file contains the test for the basic_string methods
 >> described in 21.strings.capacity. Here the same to
 >> 27.stringbuf.virtuals schema is used. But I think we need to implement


 >> our own allocator class for the test purposes to strictly test some
 >> methods (max_size, capacity). Also may be useful to develop some
 >> analogue of the algorithms tests X class to be used instead of char
 >> and wchar_t (according to the standard here may be any POD type).
 >> Martin, what do you think about this?


I agree. Exercising the template with user-defined template arguments in
addition to the default ones is important. The header file named
mychar.h contains a user-defined character type and traits class that
was designed for this purpose. The header myallocator.h defines a custom
allocator that we could use. We need to port these headers to the new
driver first (it should be pretty easy). I also want to rename them to
follow the rw_xxx.h convention.

I made a few improvements to the test and committed it here:
http://svn.apache.org/viewcvs?rev=383204&view=rev

My comments are below.

Btw., I noticed a bug in the test I decided not to fix and let you do it
 :)  The hardocded strings containing embedded NULs do not always seem to
be handled correctly (with my changes in place you will see it if you
run the test with the --trace option). The string object needs to be
initialized using the two-argument ctor.


 >>

[...]


 >>
 >> int traits_eof = -1;


This shouldn't be necessary. AFAIK, basic_string doesn't use EOF for
anything.


 >>
 >> template <class charT>
 >> struct CharTraits: std::char_traits<charT>
 >> {
 >>     typedef std::char_traits<charT> Base;
 >>     typedef typename Base::int_type int_type;


I think it would be useful to change the int_type here from the default,
say to short or something unusual.


 >>
 >>     // override eof() to detect bad assumptions
 >>     static int_type eof () { return traits_eof; }
 >>     static int_type not_eof (int_type c) {
 >>         return c == eof () ? int_type (!c) : c;
 >>     }


This shouldn't be necessary. As I mentioned above, basic_string doesn't
make use of these functions (they're good for I/O).


 >> };
 >>
 >> /*********************************************************************
 >> *****/
 >>
 >> struct VFun
 >> {
 >>     enum charT { Char, WChar };
 >>     enum Traits { DefaultTraits, UserTraits };
 >>     enum VirtualTag {
 >>         // which virtual function to exercise


Since (unlike basic_stringbuf) basic_string has no virtual functions I
changed the name of the class and of the tag to make more sense.


 >>         size, resize, length, reserve, capacity, max_size, clear,

empty

 >>     };
 >>

[...]

 >> template <class charT>
 >> void widen (charT *buf, const char *str)


This function will need to take an additional argument -- the length of
string -- to correctly handle embedded NULs.

[...]

 >>     rw_assert (should_throw == ex_thrown, 0, line,
 >>                "line %d. basic_string<%s, %s, %s>.resize(%zu%{?},

%#c%{;}) "

 >>                "on \"%s\" should throw == %b, was thrown == %b",
 >>                __LINE__, pfid->cname_, pfid->tname_, "std::allocator",
 >>                nparam, resize2args, chart_param, 0 != str ? str :

"<empty>",

 >>                should_throw, ex_thrown);


I changed this and the other statements to use the %{#*S} directive
designed for the formatting of generic basic_string objects. Check it
out, it's quite handy (so handy, in fact, that it exposed the bug I
mentioned above).

[...]

 >>     // check the results
 >>     static charT wstr_tmp [long_string_len];
 >>     widen (wstr_tmp, str);


When str contains embedded NULs they are not handled.

[...]

 >> void test_size (VFun *pfid)
 >> {
 >>     rw_info (0, 0, 0, "basic_string<%s, %s, %s>::size ()",
 >>              pfid->cname_, pfid->tname_, "std::allocator");
 >>
 >>     pfid->vfun_ = VFun::size;


I decided to move this assignment up to the caller for simplicity.


 >>
 >> #define TEST(str, size)

\

 >>     test_string_capacity (pfid, __LINE__, str, sizeof str - 1,

\

 >>                           0, 0, size, false)
 >>

[...]

I think it's better (less error-prone) to #undef the macro just before
#defining it so I moved the #undef directives immediately above the
#defines.

Martin


Mime
View raw message