Re: [boost] [TTI] Review

Subject: Re: [boost] [TTI] Review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-17 16:56:36

On 7/17/2011 1:26 PM, Lorenzo Caminiti wrote:
> On Sun, Jul 17, 2011 at 10:05 AM, Edward Diener<eldiener_at_[hidden]>  wrote:
>> On 7/16/2011 3:02 PM, Lorenzo Caminiti wrote:
>>>>> 12. [WANT] Are the metafunction MTFC macros really needed? The docs
>>>>> say they reduce compile-time (compared to using MPL placeholders) but
>>>>> no evidence is shown to support that...
>>>>>
>>>>> Extra macros complicate the library API so if they are provided for
>>>>> reducing compile-time there should be some benchmarking showing their
>>>>> benefits. If not, these macros should be removed.
>>>>>
>>>>> [NOTE] If these macros are shown to be beneficial, I'd rename them
>>>>> with a METAFUNC postfix because I find it more readable. For example:
>>>>>
>>>>>     HAS_TYPE_METAFUNC
>>>>>     HAS_MEMBER_FUNCTION_METAFUNC
>>>>
>>>> I supplied them merely as a convenience. In an early mailing list message
>>>> about the TTI library from Dave Abrahams, before this review, he
>>>> suggested
>>>> that passing metafunctions as data as a metafunction class would
>>>> generally
>>>> be faster than passing them via placeholder expressions. I do not mind
>>>> eliminating them if it seen as overkill.
>>>
>>> If there is evidence (compile-time data and possibly some explanation)
>>> of that MTFC have faster compile-time, leave the macros. However, I
>>> thinks you either (1) measure the compile-times add the evidence in
>>> the docs or (2) you remove the MTFC macros.
>>
>> Having the MTFC macros does not hurt anything. There is no reason to not
>> supply them purely as a convenience.
>
> As a user of your library, how would I decide if I should use MTFC or
> not? The docs say MTFC might be faster but the docs don't say of how
> much, for which compiler, etc. Please keep your users in mind, if you
> provide the MTFC functionality to your users, you need to provide them
> also with all the information they need to make the informed decision
> of when to use such functionality or not.

Are not users allowed to try one way or the other and then test if their 
compile times are faster or slower ?

Jeffrey Hellrung has pointed out that boost::mpl::quote is an easy way 
of creating a metafunction class from a metafunction so, unless I hear 
otherwise from reviewers who object, I will probably drop the MTFC 
macros. I am not guarantee that I will do that since in my own tests I 
use it extensively, along with placeholder expressions, and I find my 
syntax easy to use, but if I do decide to keep them around I will 
section any explanation about them off from the main documentation.

I still am a bit intrigued that so many users of a library feel that 
added macro sets ( like the MTFC macros and the GEN macros) or 
alternative functionality ( like the nullary metafunctions ), which 
could be ignored by anybody who wishes without losing any of the basic 
functionality of the macro metafunctions, somehow detract from the 
ability to use or understand the library.

>>>>> 13. [WANT] Are the nullary metafunctions really needed?
>>>>
>>>> Functionally, no, which the documentation explicitly explains.
>>>> Syntactically
>>>> I feel they are much easier to use once they are understood.
>>>>
>>>>> The docs say
>>>>> they simplify the syntax but no side-by-side example comparing the
>>>>> syntax with and without the nullary type metafunctiosn is provided...
>>>>>
>>>>> Unless their benefit is clearly shown, the nullary metafunctions
>>>>> should be remove to simplify the library API.
>>>>
>>>> I will add side by side examples showing the simpler syntax of using the
>>>> nullary metafunctions. I do show the different syntaxes for similar
>>>> situations in the doc, but not side by side.
>>>
>>> Can you please reply to this email with a short example that compares
>>> the two syntaxes so we can all take a look at it?
>>>
>>>> Why not just ignore them if you do not like their syntax ? After all
>>>> tghey
>>>
>>> Because as a new user of your library I think "are they important?",
>>> "shall I learn them?", "do I need/want their simpler syntax?". So if
>>> they really offer a benefit (even just syntactical), they should be
>>> there, just illustrate their benefit better.
>>
>> There are sections in the doc about "Nullary Type Metafunctions" and "Using
>> the Nullary Type Metafunctions". I will work on expanding the documentation
>> in these sections, perhaps adding some more sections, so that others
>> understand the syntactical advantage of using the nullary metafunctions if
>> they want to do so.
>
> Again, can you please reply to this email with a short example that
> compares the two syntaxes so we can all (i.e., all Boosters) take a
> look at it?

 From the docs ( it is really there but separated right now ) :

struct T
   {
   struct AType
     {
     struct BType
       {
       struct CType
         {
         struct FindType
           {
           };
         }
       };
     };
   };

BOOST_TTI_MEMBER_TYPE(FindType)
BOOST_TTI_MEMBER_TYPE(AType)
BOOST_TTI_MEMBER_TYPE(BType)
BOOST_TTI_MEMBER_TYPE(CType)

With macro metafunctions our syntax for creating a nested type called 
MyFindType which could refer to FindType is:

typedef typename
boost::tti::member_type_FindType
   <
   typename boost::tti::member_type_CType
     <
     typename boost::tti::member_type_BType
       <
       typename boost::tti::member_type_AType
         <
         T
         >::type
       >::type
     >::type
   >::type MyFindType;

With nullary type metafunctions the syntax to create a nested nullary 
type metafuncion which could refer to FindType is:

typedef
boost::tti::mf_member_type
   <
   boost::tti::member_type_FindType<_>,
   boost::tti::mf_member_type
     <
     boost::tti::member_type_CType<_>,
     boost::tti::mf_member_type
       <
       boost::tti::member_type_BType<_>,
       boost::tti::member_type_AType
         <
         T
         >
       >
     >
   > MyFindType;

I think the nullary type syntax is cleaner syntactically and easier to 
use. There may be a better solution for this sort of thing, but I am 
looking for simplicity.

The whole idea, syntactically, of the nullary type metafunctions is that 
one passes around the metafunction itself rather than its nested type, 
so there is much less of the ::type in the syntax. It does involve using 
a separate set of boost::tti::mf_xxx metafunctions and passing 
metafunctions as data, but I feel that the syntactical gain is worth it.

I really will update my documentation so that I will compare the macro 
metafunction and nullary type metafunction usage together when dealing 
with all of the cases of using the non-composite macro metafunctions.

Eddie