* Added default-value for cmdline-option which expects the Boost
source-directory. It points to the Boost source-directory in which the
script "boost_mpl_preprocess.py" is located.
* Adjusted "README.txt" file to reflect these changes.
Signed-off-by: Deniz Bahadir <dbahadir@benocs.com>
* Extended script "boost_mpl_preprocess.py" to automatically call script
"fix_boost_mpl_preprocess.py" prior to pre-processing and thereby
automatically fix issue #11224.
* Extended script "fix_boost_mpl_preprocess.py" to just allow checking
if the selected Boost source-directory requires fixing because of
issue #11224.
* Adjusted the "README.txt" accordingly.
Signed-off-by: Deniz Bahadir <dbahadir@benocs.com>
* Corrected a small error in a regex of "boost_mpl_preprocess.py" which
did match too much and therefore resulted in wrong substitution in
some cases.
* Added some more directories with files that need fixing to script
"fix_boost_mpl_preprocess.py".
Signed-off-by: Deniz Bahadir <dbahadir@benocs.com>
Python-script "fix_boost_mpl_preprocess.py" fixes the header-problems
described in issue #11224.
Python-script "boost_mpl_preprocess.py" simplifies the pre-processing of
MPL-containers.
Signed-off-by: Deniz Bahadir <dbahadir@benocs.com>
Originally Tickets 7975 and 8749 referred only to insertion of keys into
maps, but the very same bug can be reproduced for sets as well.
Moreover, the removal of keys from both also suffers of the same bug.
Test cases are based on calling apply to forward to the and_ predicate
an increasing number, from 2 to 15, of true_ constants. Since the arity
limit on the current version is set to 5,
BOOST_MPL_LIMIT_METAFUNCTION_ARITY and
BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS must be appropriately set.
Taking advantage of the fact that order of insertion doesn't really
matter for associative sequences.
Comparing to the default implementation, which at any rate does work for
associative sequences, this specialization essencially avoids
reinserting every element of Sequence into a new sequence, besides the
fact no joint_view nor iterator_range needs to be instantiated.
This way we take advantage of the constant-time insertion and removal of
elements at the beginning of Front Extensible sequences, such as list.
This implementation is closer to the original.
According to reference, insert_range should work for any Extensible
sequence or Extensible Associative sequence, but the default
implementation of insert_range_impl assumes a front_inserter is defined
for the given sequence, but neither Extensible nor every Extensible
Associative sequences are required to also be a Front Extensible
sequence. This fix rely only on insert, which is defined for every
Extensible sequence.
