From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-19 06:09:16
David Abrahams wrote:
> Tobias Schwinger <tschwinger_at_[hidden]> writes:
>
>
>>David Abrahams wrote:
>>
>>>[...] 1. Proof it
>>
>>It has been applied to Boost.Lambda and to boost:mem_fn (which is a part of Bind).
>>
>>I'll attach the results to the end of this post. An archive containing the
>>results, all refactored code and a diff for Boost.Lambda (to easily spot the
>>changes) has been uploaded to the vault:
>>
>> http://tinyurl.com/c3tpv
>
>
> Can you say a little something to help me understand the wc numbers
> you give at the end of your post?
>
Sure. Sorry for the too brief summary. It was late in my timezone and I had to
get some sleep.
'wc' is a Unix shell command and stands for "word count" (I'm pretty sure you
know that - but some readers might not). With the '-l' it counts the number of
lines in (a) file(s).
Since you requested to find out the portential of Function Types to eliminate
existing/redundant Boost code, the output of the 'wc' command was meant to
document ammount of factored out code.
--- Function template boost::mem_fn (lives in the directory of Boost.Bind)
The original uses files with different versions of templates for arity 0-9 and
macros in them. These are repetetively included with different macro definitions
to generate variations for different calling conventions and with or without
'return' (if BOOST_NO_VOID_RETURNS is set).
The changed version does not need these variations. And because it's tedious too
do everything ten times, I used Boost.Preprocessor to help me with it (for the
arity part).
For counting lines, however, I used an already-preprocessed version of this file
(because we want to measure Function Types and not Boost.Preprocessor).
Without BOOST_NO_VOID_RETURNS and only the default calling convention we end up
with 936 lines less (the original version needs 1561 lines total - my version
needs 625 -- actually 325 but this would be "unfair" because of using
Boost.Preprocessor).
The footnotes indicate how the preprocessed size of the library scales up, when
certain features or workarounds are enabled.
--- The Function Types library applied to Boost.Lambda:
There are 464 lines less in the Lambda library.
It can theoretically take advantage of the common configuration - in practice
Type Traits still keeps it from working with any calling convention.
This file contains the code for handling member pointers:
changed 358 lines in lambda/detail/member_ptr.hpp
original 737 lines in lambda.bak/detail/member_ptr.hpp
This file contains the functor frontend for lambda functors, data members and
functions:
changed 519 lines in lambda/detail/function_adaptors.hpp
original 640 lines in lambda.bak/detail/function_adaptors.hpp
A wrapper for 'function_type_class' (to decorate cv-qualification) has been put
here. This will not be needed anymore with the next version of Function Types:
changed 556 lambda/detail/lambda_traits.hpp
original 527 lambda.bak/detail/lambda_traits.hpp
See the diff file included in the archive for details (it's too large to post it
here).
Hope this works. Please ask if something is unclear.
Regards,
Tobias