Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <446E03EF.6070606@roguewave.com>
Date: Fri, 19 May 2006 11:44:15 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: test for lib.string::operator+
References: <4D6A8407B7AC6F4D95B0E55C4E7C4C62043B0AA2@exmsk.moscow.vdiweb.com>
In-Reply-To: 
 <4D6A8407B7AC6F4D95B0E55C4E7C4C62043B0AA2@exmsk.moscow.vdiweb.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

FWIW, I prefer the name FunctionId to MethodId as the term "method"
has the connotation of a virtual function (from OO programming).

Btw., it occurs to me that we might be able to simplify things
quite a bit (especially the formatting of signatures) by changing
SignatureId from an enum into a bitmap with a separate field for
each argument.

We have the following possible argument types:

    0: arg_void (void/none)
    1: arg_size (size_type)
    2: arg_val (value_type)
    3: arg_ptr (pointer)
    4: arg_c_ptr (const_pointer)
    5: arg_ref (reference)
    6: arg_c_ref (const_reference)
    7: arg_iter (iterator)
    8: arg_c_iter (const_iterator)
    9: arg_cont (container& or this for member functions)
   10: arg_c_cont (const container& or const this for members)
   10 - 15: (reserved)

and at most 5 arguments:

   replace (size_type, size_type, const_pointer, size_type, size_type)

So the new SignatureId (renamed to SignatureMap :) for this overload
of replace would look like this:

   /* 0th argument */   arg_cont // the *this object
   /* 1st argument */   arg_size  <<  4
   /* 2nd argument */ | arg_size  <<  8
   /* 3rd argument */ | arg_c_ptr << 12
   /* 4th argument */ | arg_size  << 16
   /* 5th argument */ | arg_size  << 20

To simplify the definition of signatures we could define a few
convenience macros:

   // for non-member functions
   #define SIG_0()                arg_void
   #define SIG_1(a1, a2)          arg_##a1 | arg_##a2
   ...
   #define SIG_5(a1, ..., a5)     arg_##a1 | ... | arg_##a5

   // for member functions
   #define MEM_0(c)               arg_##c
   #define MEM_1(c, a1, ..., a5)  arg_##c | arg_##a1 | ... | arg_##a5
   ...

and use MEM_5 to define the replace signature above like so:

    MEM_5(cont, size, size, c_ptr, size, size)

With this arrangement the formatting function would simply iterate
through the signature bitmap one 4-bit field at a time, appending
the argument type encoded in each field to the end of the string
until the type is void.

Martin