From stdcxx-dev-return-1035-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Sat Mar 04 22:02:18 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 34762 invoked from network); 4 Mar 2006 22:02:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 Mar 2006 22:02:18 -0000 Received: (qmail 2793 invoked by uid 500); 4 Mar 2006 22:03:04 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 2768 invoked by uid 500); 4 Mar 2006 22:03:04 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 2756 invoked by uid 99); 4 Mar 2006 22:03:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Mar 2006 14:03:03 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 04 Mar 2006 14:03:02 -0800 Received: from bco-exchange.bco.roguewave.com (bco-exchange.bco.roguewave.com [172.19.31.48]) by moroha.quovadx.com (8.13.4/8.13.4) with ESMTP id k24M1ZBP029131 for ; Sat, 4 Mar 2006 22:02:39 GMT Received: from [10.70.3.113] (10.70.3.113 [10.70.3.113]) by bco-exchange.bco.roguewave.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id F5YGRSQ7; Sat, 4 Mar 2006 15:01:49 -0700 Message-ID: <440A0F89.2020201@roguewave.com> Date: Sat, 04 Mar 2006 15:07:05 -0700 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: test for 21.strings.capacity References: <44086C71.6090207@moscow.vdiweb.com> In-Reply-To: <44086C71.6090207@moscow.vdiweb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 > struct CharTraits: std::char_traits > { > typedef std::char_traits 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 > 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 : "", > 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