From stdcxx-dev-return-1381-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Tue May 23 14:28:51 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 5041 invoked from network); 23 May 2006 14:28:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 May 2006 14:28:46 -0000 Received: (qmail 49471 invoked by uid 500); 23 May 2006 14:27:17 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 49362 invoked by uid 500); 23 May 2006 14:27:16 -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 49196 invoked by uid 99); 23 May 2006 14:27:16 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 May 2006 07:27:16 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of AntonP@moscow.vdiweb.com designates 195.210.189.132 as permitted sender) Received: from [195.210.189.132] (HELO mail.moscow.vdiweb.com) (195.210.189.132) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 May 2006 07:27:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: test for lib.string::operator+ Date: Tue, 23 May 2006 18:26:45 +0400 Message-ID: <4D6A8407B7AC6F4D95B0E55C4E7C4C6204436722@exmsk.moscow.vdiweb.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: test for lib.string::operator+ Thread-Index: AcZ9sfOxvxJFgdyzS2GIOicxAB35VwAu9d/g From: "Anton Pevtsov" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Three new tests for non-members (include operator+ test) with required changes to 21.strings.h/.cpp with new enums are here: http://people.apache.org/~antonp/stdcxx05232006/ With best wishes, Anton Pevtsov -----Original Message----- From: Anton Pevtsov [mailto:antonp@moscow.vdiweb.com]=20 Sent: Monday, May 22, 2006 19:10 To: stdcxx-dev@incubator.apache.org Subject: Re: Re: test for lib.string::operator+ Martin Sebor wrote: > <>I've been playing with this a bit and it turns out that we do have > <>enough bits if we only make better use of them :) Here's how we can=20 > squeeze all the functions and their signatures into 32 bits: [...] > <>A 32-bit OverloadId enum has room for the 5 bit MemberId and up to=20 > six 4-bit ArgId's. Since no string member function has more than > <>5 arguments we even have 3 whole bits to spare! :) > Great! One minor question: what about non-members? The enum is still named MemberId, so the adding elements for non-members into it looks inconvenient. But I updated the operator+ test using the latest versions of enums. The diffs and the test are attached. <> Martin Sebor wrote: > <>Btw., you will notice that I've introduced arg_alloc and a bunch of > <>new ctor constants, one for each of the basic_string ctors that=20 > takes an Allocator argument, so we'll be ready can extend the ctor=20 > test to exercise the allocators. > I see, thanks. I'll update the test when the changes to=20 21.strings.h/.cpp appears on the svn. Thanks, Anton Pevtsov. > <> > > -----Original Message----- > From: Martin Sebor [mailto:sebor@roguewave.com] > Sent: Sunday, May 21, 2006 04:15 > To: stdcxx-dev@incubator.apache.org > Subject: Re: test for lib.string::operator+ > > > Martin Sebor wrote: > >>=20 >>=20 >> I think it might be easier to simply change Function to >>=20 >> struct Function { >> charT char_id_; >> Traits traits_id_; >> Allocator alloc_id_; >> FunctionId fun_id_; >> SignatureId sig_id_; >> }; >>=20 >> and dispense with OverloadId altogether. It hasn't proved to be >> terribly useful anyway. > =20 > I've been playing with this a bit and it turns out that we do have enough bits if we only make better use of them :) Here's how we can squeeze all the functions and their signatures into 32 bits: 5 bits: MemberId with room for 32 functions (20 are used so we have room for 12 more; if that's not enough it's trivial to extend the field to 6 bits) 4 bits: ArgId, encodes argument type, room for 16 types (12 are used so we have room for 4 more, including basic_istream and basic_ostream; there's no room for extension beyond that) A 32-bit OverloadId enum has room for the 5 bit MemberId and up to six 4-bit ArgId's. Since no string member function has more than 5 arguments we even have 3 whole bits to spare! :)=20 I'm not quite done making the changes yet but I've made good progress. The diffs of what I have so far are attached for your preview. The changes compile but since I've changed the names of a couple of the constants (ptr to cptr and ref to cref) none of the tests does. I will make the corresponding changes in the tests as soon as I'm done. What remains is to implement a mapping from the OverloadId bitmap to an ordinal number that can be used as an index into the command line option array. Btw., you will notice that I've introduced arg_alloc and a bunch of new ctor constants, one for each of the basic_string ctors that takes an Allocator argument, so we'll be ready can extend the ctor test to exercise the allocators. Martin