From stdcxx-dev-return-1415-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Thu Jun 01 01:20:38 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 78965 invoked from network); 1 Jun 2006 01:20:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Jun 2006 01:20:38 -0000 Received: (qmail 22060 invoked by uid 500); 1 Jun 2006 01:20:38 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 22049 invoked by uid 500); 1 Jun 2006 01:20:37 -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 22037 invoked by uid 99); 1 Jun 2006 01:20:37 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 18:20:37 -0700 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; Wed, 31 May 2006 18:20:35 -0700 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.4/8.13.4) with ESMTP id k511Jwjd029060 for ; Thu, 1 Jun 2006 01:19:58 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 19:20:23 -0600 Message-ID: <447E40FC.7010405@roguewave.com> Date: Wed, 31 May 2006 19:21:00 -0600 From: Martin Sebor Organization: Rogue Wave Software 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: lib.string.capacity test update References: <4D6A8407B7AC6F4D95B0E55C4E7C4C62044F59F1@exmsk.moscow.vdiweb.com> In-Reply-To: <4D6A8407B7AC6F4D95B0E55C4E7C4C62044F59F1@exmsk.moscow.vdiweb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2006 01:20:24.0045 (UTC) FILETIME=[8EA459D0:01C68519] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Anton Pevtsov wrote: [...] > 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? It's a good start. I wonder if you could commit the first set of changes to the cons.cpp test (i.e., those that don't involve the allocator members), and then post just the diff for the rest in a separate patch. That way it will be easier to focus only on the those without getting distracted by the former. As a general comment, we should be on the lookout for ways to reduce the amount of boilerplate code that will end up repeated across all tests, such the snippet of code below. It would be nice to be able to say something like: start_counting_calls_to_allocator_members (/* ... */); // do things to string that are expected to make use // of allocator members verify_number_of_calls_to_allocator_members (/*... */); Where the /* ... */ might specify the set of allocator members whose calls we want to count and verify. It could be a bitset (e.g., in the form: m_allocate | m_deallocate | m_construct | m_destroy), or it could be a list of individual arguments, or some more complicated data structure. There should also be a way to specify that we expect "no more than" or "at least as many as" some number of calls. Or, alternatively, the first call to start counting all calls (i.e., simply zero out all the counters) and the second call would specify the expected values of each counter with the expected fuzziness factor which could be great enough for us to ignore some counters altogether. Let me see what I can cook up tomorrow. Martin PS The current hunk of code that I'm proposing to replace is below: std::size_t total_alloc_calls [SharedAlloc::n_funs]; std::size_t alloc_calls_idx [] = { SharedAlloc::m_construct, SharedAlloc::m_allocate, SharedAlloc::m_max_size }; // for convenience std::size_t idxs = sizeof alloc_calls_idx / sizeof *alloc_calls_idx; for (std::size_t t = 0; t < idxs; t++) { total_alloc_calls [alloc_calls_idx [t] ] = pal->n_calls_ [alloc_calls_idx [t] ]; } // ... const bool verify_alloc = test_alloc && func.alloc_id_ == StringIds::UserAlloc && ret_ptr->size (); if (verify_alloc) { for (std::size_t t = 0; t < idxs; t++) { bool success = total_alloc_calls [alloc_calls_idx [t] ] < pal->n_calls_ [alloc_calls_idx [t] ]; rw_assert (success, 0, tcase.line, "line %d. %{$FUNCALL} %{/*.*Gs} " "construction: expected at least 1 call of " "Allocator method %s, got 0", __LINE__, cwidth, int (ret_ptr->size ()), ret_ptr->data (), rw_get_alloc_funname (alloc_calls_idx [t])); } } delete ret_ptr;