Some 3rdparty parsers (e.g. Qt moc) fail to parse the bitand.hpp
due to the fact that bitand is a keyword in C++, not a macro.
Modern MSVC versions define bitand/bitor only if __cplusplus macro
is not defined, see iso646.h: https://pastebin.com/zTcd0juT
Thus, boost can also check the macro only in C mode making moc happy
* It normally should not be necessary to use the _Z form of the BOOST_PP_ENUM macro, although it is perfectly legal and helpful to do so, but in this case it is necessary as a workaround for a bug in the new VC++ standard conforming preprocessor. The bug manifests itself when testing the TTI library, which internally uses the Boost MPL code. The bug in the new VC++ standard conforming compiler is fixed in the VS2019 preview product, so that fix is sure to find its way to the official VS2019 product sometime soon. In the meantime this "fix" shortens the macro expansion somewhat and, while it should not be necessary, is still helpful.
* Fix for appveyor.yml file
* Added VS2019 tests, also with new preprocessor. Further MPL Fixes for new preprocessor bug, which are also useful and will speed up preprocessing.
* Can't seem to test msvc-10.0 or msvc-11.0 any more with Appveyor
* Update description
The struct member function inside BOOST_MPL_ASSERT_MSG_IMPL was causing
multiple definitions of the same symbol when used inside e.g. template
functions.
An example of where this is a big issue is in the boost/geometry library
where you currently only can call each function once for each geometry
or you get hit by the multiple definitions linking error.
This fix* works around the issue by gracefully degrading to
BOOST_STATIC_ASSERT_MSG instead of failing during linking.
Add PGI C++ to list of compilers that use enums rather than static constants for compile-time assertions, because, like GCC, PGI issues warnings for unused static constants.
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.
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.
