From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2004-09-03 10:51:01
The HMTL version of the changelog is available at
http://www.mywikinet.com/mpl/mpl_1_32_changelog.html
MPL changelog for 1.32 release
******************************
The following summarizes major changes in the library interface and
implementation from the previous release, with the accent on backward
compatibility. Note that this is *not* a comprehensive list of all
changes (yet).
Apply/lambda semantics
----------------------
1. Nullary metafunction classes are no longer special-cased, and
are *not* identical to nullary metafunctions:
+-------------------------+---------------+---------------------------+
| Nullary... | Before | Now |
+=========================+===============+===========================+
| metafunction | ``f::type`` | ``f::type`` |
+-------------------------+---------------+---------------------------+
| metafunction class | ``c::type`` | ``c::apply<>::type`` or |
| | | ``c::apply::type`` [1]_ |
+-------------------------+---------------+---------------------------+
This fixes a flaw in the metafunction/metafunction class algebra
that long has been the major source of other inconsistencies throughout
the library.
2. ``apply`` now automatically invokes ``lambda`` on its first argument, e.g.
the following is well-formed now::
typedef apply< plus<_1,_1>, int_<2> >::type four;
``apply_wrap``\ *n* auxiliary metafunctions are available for rare cases
when it's crutial to eliminate small overhead associated with lambda
expressions while still avoiding various compiler bugs known to lurk in
the obvious ``f::template apply<...>::type``.
3. Lambda implementation for broken compilers has been reworked to match
as close as possible the semantics of the full-fledged version; consequently,
there might be some incorrect code out there that will stop working with the
new implementation.
To get the detailed picture of the new apply/lambda semantics, please see
the corresponding test case at
http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/apply.cpp?view=markup.
.. [1] The second form is available only on fully conforming compilers.
Iterator protocol
-----------------
The library no loger guarantees nor relies on the direct presence of ``advance`` /
``distance`` / ``next`` / ``prior`` / ``type`` members in iterator types; the
following table summarises the new requirements:
+-------------------------------+-------------------------------+
| Before | Now |
+===============================+===============================+
| ``i::type`` | ``deref<i>::type`` |
+-------------------------------+-------------------------------+
| ``i::next`` | ``next<i>::type`` |
+-------------------------------+-------------------------------+
| ``i::prior`` | ``prior<i>::type`` |
+-------------------------------+-------------------------------+
| ``i::advance<n>::type`` | ``advance<i,n>::type`` |
+-------------------------------+-------------------------------+
| ``i::distance<j>::type`` | ``distance<i,j>::type`` |
+-------------------------------+-------------------------------+
| ``i::category`` | ``i::category`` |
+-------------------------------+-------------------------------+
Sequence traits protocol
------------------------
Sequence algorithms' traits protocol has been changed to that of metafunction
classes:
+------------------------------------------------+------------------------------------------+
| Before | Now |
+================================================+==========================================+
| *name*\ ``_traits<Tag>::algorithm<...>::type`` | *name*\ ``_impl<Tag>::apply<...>::type`` |
+------------------------------------------------+------------------------------------------+
Correspondingly, if your code implemented a custom sequence, it needs to be
adjusted according to the above table; for example:
+-----------------------------------------------+-------------------------------------------+
| Before | Now |
+===============================================+===========================================+
|:: |:: |
| | |
| template<> struct begin_traits<my_tag> | template<> struct begin_impl<my_tag> |
| { | { |
| template< typename S > struct algorithm | template< typename S > struct apply |
| { | { |
| typedef ... type; | typedef ... type; |
| }; | }; |
| }; | }; |
| | |
+-----------------------------------------------+-------------------------------------------+
Numeric metafunctions protocol/infrastructure
---------------------------------------------
The arithmetic, comparison and bitwise metafunctions are `polymorphic`,
and can operate on a variety of numeric types, including rational,
fixed-point and complex numbers. The metafunctions allow `mixed arithmetic`,
meaning that you can perform an operation on the arguments of different
types, and the result will yeild the largest/most general of the arguments
types. The infrastructure is provided to allow easy plugging of user-defined
numeric types which can be made freely intermixable with predefined
library types. See
http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/numeric_ops.cpp?view=markup
for an illustrative example.
If you were using MPL numeric metafunctions on your own integral wrapper
class similar to ``mpl::int_``, you can plug it into the new infrustructure
by extending the class with the following member::
typedef mpl::integral_c_tag tag;
For example:
+---------------------------------------+-------------------------------------------+
| Before | Now |
+=======================================+===========================================+
|:: |:: |
| | |
| template< int n > struct my_int | template< int n > struct my_int |
| { | { |
| static int const value = n; | typedef mpl::integral_c_tag tag; |
| typedef my_iny type; | static int const value = n; |
| }; | typedef my_iny type; |
| | }; |
| | |
+---------------------------------------+-------------------------------------------+
Renaming/cleanup
----------------
1. ``apply_if`` metafunction has been renamed to ``eval_if``.
2. All ``_backward`` algorithm counterparts have been renamed to use ``reverse_``
prefix; e.g. ``fold_backward`` became ``reverse_fold``.
3. ``<boost/mpl/aux_/has_xxx.hpp>`` header has been made public and became
``<boost/mpl/has_xxx.hpp>``; correspondingly, the ``BOOST_MPL_NO_AUX_HAS_XXX``
macro was renamed to ``BOOST_MPL_CFG_NO_HAS_XXX``.
4. ``<boost/mpl/assert_is_same.hpp>`` header has been replaced by a more
general ``<mpl/assert.hpp>``; the new asserts provide a significantly
higher-quality diagnostics. See the table below for the new equivalents of
the old macros:
+-------------------------------------------+-----------------------------------------------------+
| Before | Now |
+===========================================+=====================================================+
| ``BOOST_MPL_ASSERT_IS_SAME(t1, t2)`` | ``BOOST_MPL_ASSERT(( boost::is_same<t1,t2> ))`` |
+-------------------------------------------+-----------------------------------------------------+
| ``BOOST_MPL_ASSERT_IS_NOT_SAME(t1, t2)`` | ``BOOST_MPL_ASSERT_NOT(( boost::is_same<t1,t2> ))`` |
+-------------------------------------------+-----------------------------------------------------+
5. All configuration macros has been renamed to include ``CFG`` prefix; in
particular, ``BOOST_MPL_NO_FULL_LAMBDA_SUPPORT`` has become
``BOOST_MPL_CFG_NO_FULL_LAMBDA_SUPPORT``.
6. The following other public headers/components has been renamed or removed as
obsolete::
iterator_tag.hpp (renamed to iterator_tags.hpp)
project1st.hpp
project2nd.hpp
select1st.hpp
select2nd.hpp
Miscellaneous
-------------
1. ``vector`` has been re-implemented to support constant-time
insertion at both the beginning and the end. For example, this is now
well-formed::
typedef push_back<v,int>::type v1;
typedef push_front<v1,int>::type v2;
2. The interface of some sequence building algorithms such as ``copy``
has been changed. Please see the corresponding headers for the details
(updated docs are upcoming!).
-- Aleksey Gurtovoy MetaCommunications Engineering