Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 66.249.82.234 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=j/rBokKi1q2UY6xFoVdufA0tvWWMrUGa9aUWh2LVIt9MD5WmrOKVpvFMGR83SEIVZ5+RuG7zrLIKM8QFVZygABsxL1q+HU8AHw/RZh4pyX/wbuGUkmCU2oHNaM4bsu/ECsVzajY8KfPyATYb/ZgJcHk+i5hNxzfolSt0iFpSm7Q=
Message-ID: <4841C60F.5010408@roguewave.com>
Date: Sat, 31 May 2008 15:41:35 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: type_traits progress
References: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA862@exchmail01.Blue.Roguewave.Com>
 <483B79A1.4070808@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA864@exchmail01.Blue.Roguewave.Com>
 <483C67BA.6070209@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86C@exchmail01.Blue.Roguewave.Com>
 <48401E00.2090709@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86D@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A37ED@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA86E@exchmail01.Blue.Roguewave.Com>
 <48406BE1.4070902@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A37F3@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A37F3@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Friday, May 30, 2008 3:05 PM
>> To: dev@stdcxx.apache.org
>> Subject: Re: type_traits progress
>>
>> Travis Vitek wrote:
>>>  
>>>
>>> Eric Lemings wrote:
>>>>> Travis Vitek wrote:
>>>>>  
>>>> ...
>>>>> As an example, the array traits above are all closely related 
>>>>> and their
>>>>> implementations are similar. There are five traits, and 
>> those traits
>>>>> span three sections of the standard.
>>>>>
>>>>> I'm open to doing some type of grouping, we just need to 
>>>>> understand how
>>>>> we want to group them and then how we want to name the files.
>>>> The term you're looking for is cohesion.  :)  I kinda like this
>>>> organization.  Couple things though.
>>>>
>>>> Why put __rw_decay, a single helper trait in its own header?
>>> Well decay deals with conversion from array to pointer and 
>> function to
>>> function pointer conversions. I can't necessarily put it into both
>>> _meta_array.h and _meta_func.h, so I figured it would be 
>> best to put it
>>> into a file by itself.
>> FWIW, I see no problem with bundling groups of traits together
>> even if some of them are unlikely to be used in the rest of the
>> lib, just as long as their implementation isn't too big (i.e.,
>> doesn't bloat translation units and unnecessarily increase
>> compilation time).
> 
> Well when it comes to metaprogramming, there's almost always a
> tradeoff in these two respects.  Either the translation unit
> size increases or compile times increase.

They tend to go hand in hand. But you probably meant the size
of the generated object code.

> But you're right:
> we should minimize both whenever possible.
> 
> BTW, which of these two should be the preferred: comile-time
> computations (metaprogramming) or runtime processing?  I would
> say compile-time even though that will signficantly impact us
> developers but I think users would prefer this since they do
> not build nearly as often.

I'm sure you're right in the majority of cases. But as John Lakos
writes in his Large-Scale C++ Software Design compilation time is
exceedingly important for large code bases with millions of lines
of code: http://www.amazon.com/dp/0201633620

The problem with metaprogramming is that many compilers weren't
designed for the kind of involved computation that some of these
algorithms require, so their performance really blows. It's a
fun exercise to time the compilation of a non-trivial metaprogram
(e.g., sorting a typelist) while watching its memory consumption.

Martin