incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: test for lib.string::operator+
Date Sun, 21 May 2006 00:14:53 GMT
Martin Sebor wrote:
> Anton Pevtsov wrote:
> 
>> Martin Sebor wrote:
>> [...]
>>
>>> I also think we can do better than hardcode assumptions about the
>>
>>
>> order of the constants (the computation of the nonmember constant in
>> 21.strings.cpp).
>>
>> Hmm, shall we separate members indexes or enum elements (and
>> signatures?) from the nonmember ones?
>> Or we may have something like
>> struct OverloadId {
>>     MethodId method_id;
>>     SignatureId signature_id;
>> };
>>
>> where MethodId enum is organized like SignatureId and includes all
>> methods, operators (including non-memebres) to be tested?
> 
> 
> 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