You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Anton Pevtsov <an...@moscow.vdiweb.com> on 2006/03/03 17:18:57 UTC
test for 21.strings.capacity
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?
With best wishes,
Anton Pevtsov
Re: test for 21.strings.capacity
Posted by Martin Sebor <se...@roguewave.com>.
Martin Sebor wrote:
> 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 just committed the rw_char.h header:
http://svn.apache.org/viewcvs?rev=383236&view=rev
Let me know how it works out for you.
Martin
Re: test for 21.strings.capacity
Posted by Martin Sebor <se...@roguewave.com>.
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