Boost logo

Boost :

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:
> 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

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

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

Hope this works. Please ask if something is unclear.



Boost list run by bdawes at, gregod at, cpdaniel at, john at