[ceph.git] / ceph / src / boost / libs / mpl / doc / src / refmanual / Metafunctions.rst


The MPL includes a number of predefined metafunctions that can be roughly
classified in two categories: `general purpose metafunctions`, dealing with
conditional |type selection| and higher-order metafunction |invocation|, 
|composition|, and |argument binding|, and `numeric metafunctions`, 
incapsulating built-in and user-defined |arithmetic|, |comparison|, 
|logical|, and |bitwise| operations.

Given that it is possible to perform integer numeric computations at 
compile time using the conventional operators notation, the need for the 
second category might be not obvious, but it in fact plays a cental role in 
making programming with MPL seemingly effortless. In 
particular, there are at least two contexts where built-in language 
facilities fall short [#portability]_\ :

1) Passing a computation to an algorithm.
2) Performing a computation on non-integer data.

The second use case deserves special attention. In contrast to the built-in,
strictly integer compile-time arithmetics, the MPL numeric metafunctions are 
*polymorphic*, with support for *mixed-type arithmetics*. This means that they 
can operate on a variety of numeric types |--| for instance, rational, 
fixed-point or complex numbers, |--| and that, in general, you are allowed to 
freely intermix these types within a single expression. See |Numeric 
Metafunction| concept for more details on the MPL numeric infrastructure.

.. The provided `infrastructure`__ allows easy plugging of user-defined numeric 
   types
   Naturally, they also , meaning that you can perform a computation on the 
   arguments of different types, and the result will yeild the largest/most general 
   of them. For user-defined numeric types, they provide an `infrastructure`__ that 
   allows easy plugging and seemless integration with predefined library 
   types. details.

   __ `Numeric Metafunction`_


To reduce a negative syntactical impact of the metafunctions notation
over the infix operator notation, all numeric metafunctions
allow to pass up to N arguments, where N is defined by the value of
|BOOST_MPL_LIMIT_METAFUNCTION_ARITY| configuration macro.


.. [#portability] All other considerations aside, as of the time of this writing 
   (early 2004), using built-in operators on integral constants still often 
   present a portability problem |--| many compilers cannot handle particular 
   forms of expressions, forcing us to use conditional compilation. Because MPL
   numeric metafunctions work on types and encapsulate these kind of workarounds 
   internally, they elude these problems, so if you aim for portability, it is 
   generally adviced to use them in the place of the conventional operators, even 
   at the price of slightly decreased readability.
Commit	Line	Data
7c673cae FG	1
	2	The MPL includes a number of predefined metafunctions that can be roughly
	3	classified in two categories: `general purpose metafunctions`, dealing with
	4	conditional \|type selection\| and higher-order metafunction \|invocation\|,
	5	\|composition\|, and \|argument binding\|, and `numeric metafunctions`,
	6	incapsulating built-in and user-defined \|arithmetic\|, \|comparison\|,
	7	\|logical\|, and \|bitwise\| operations.
	8
	9	Given that it is possible to perform integer numeric computations at
	10	compile time using the conventional operators notation, the need for the
	11	second category might be not obvious, but it in fact plays a cental role in
	12	making programming with MPL seemingly effortless. In
	13	particular, there are at least two contexts where built-in language
	14	facilities fall short [#portability]_\ :
	15
	16	1) Passing a computation to an algorithm.
	17	2) Performing a computation on non-integer data.
	18
	19	The second use case deserves special attention. In contrast to the built-in,
	20	strictly integer compile-time arithmetics, the MPL numeric metafunctions are
	21	polymorphic, with support for mixed-type arithmetics. This means that they
	22	can operate on a variety of numeric types \|--\| for instance, rational,
	23	fixed-point or complex numbers, \|--\| and that, in general, you are allowed to
	24	freely intermix these types within a single expression. See \|Numeric
	25	Metafunction\| concept for more details on the MPL numeric infrastructure.
	26
	27	.. The provided `infrastructure`__ allows easy plugging of user-defined numeric
	28	types
	29	Naturally, they also , meaning that you can perform a computation on the
	30	arguments of different types, and the result will yeild the largest/most general
	31	of them. For user-defined numeric types, they provide an `infrastructure`__ that
	32	allows easy plugging and seemless integration with predefined library
	33	types. details.
	34
	35	__ `Numeric Metafunction`_
	36
	37
	38	To reduce a negative syntactical impact of the metafunctions notation
	39	over the infix operator notation, all numeric metafunctions
	40	allow to pass up to N arguments, where N is defined by the value of
	41	\|BOOST_MPL_LIMIT_METAFUNCTION_ARITY\| configuration macro.
	42
	43
	44	.. [#portability] All other considerations aside, as of the time of this writing
	45	(early 2004), using built-in operators on integral constants still often
	46	present a portability problem \|--\| many compilers cannot handle particular
	47	forms of expressions, forcing us to use conditional compilation. Because MPL
	48	numeric metafunctions work on types and encapsulate these kind of workarounds
	49	internally, they elude these problems, so if you aim for portability, it is
	50	generally adviced to use them in the place of the conventional operators, even
	51	at the price of slightly decreased readability.
	52
	53
	54