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 lib.string::operator+
Date Mon, 22 May 2006 15:10:26 GMT
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
> 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 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 takes an
> Allocator argument, so we'll be ready can extend the ctor test to
> exercise the allocators.
>

I see, thanks. I'll update the test when the changes to 
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:

>
>> 
>> 
>> I think it might be easier to simply change Function to
>> 
>>     struct Function {
>>         charT       char_id_;
>>         Traits      traits_id_;
>>         Allocator   alloc_id_;
>>         FunctionId  fun_id_;
>>         SignatureId sig_id_;
>>     };
>> 
>> and dispense with OverloadId altogether. It hasn't proved to be 
>> terribly useful anyway.
>  
>

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!  :) 

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


Mime
View raw message