- Boost - lists.preview.boost.org

[fusion] Definition for FUSION_MAX_MAP_SIZE
by Edward Diener 01 Jul '14

01 Jul '14

The documentation for fusion implies that FUSION_MAX_MAP_SIZE is defined whenever a fusion header is included. is this so ? Testing this out under Wave suggests it is not so. What fusion header needs to be included in order to bring in the definition for FUSION_MAX_MAP_SIZE ?

3 6

Intel 14.0.1 error with boost::bind
by Aniket Pugaonkar 01 Jul '14

01 Jul '14

Hi, I am using a test program for compiling a boost::bind in Intel MIC(Xeom Phi). Here are the details of the code and platform on which it is compiled. I am using thread building blocks in my code, but the following code does not contain any TBB threads. The errors in my test code below and original code are same. Compiler : Intel 13.0.1 / intel 14.0.1 SP1 Update 3 (latest from intel composer XE trial version) I am using our lab's compiler installed on a cluster. The TBB is installed in my home directory. boost 1.55 is also installed in my home location. Compiled for MIC: icpc -mmic -L/home/aniketnp/tbb42_20140122oss/lib/mic -std=c++11 -I/home/aniketnp/boost_1_55_0 -I/home/aniketnp/tbb42_20140122oss/include test.cpp Scenario: a functor takes 2 arguments in its operator()() by using a boost::bind() method. The operator()() method contains a function which uses comparisons ( < or > ) using if-else logic. The error pops up here. Here is the following code. #include <iostream> #include <boost/bind.hpp> using namespace std; struct Info_t { int start; int end; Info_t(int s=0,int e=0) : start(s), end(e) { } }; template <typename T, typename time> void process_info(const T& info1, const T& info2, const time& t) { //the below gives compiler error * if ((info1.start < info2.end) && (info2.end > info1.end) && (info1.end < info2.start) )* std::cout << "yess error with mic" << std::endl; //the below if works fine if ((info1.start < info2.end) && (info2.end > info1.end)) std::cout << "no error at all" << std::endl; } template<typename Time> struct my_functor { public: my_functor() { } my_functor(Time& time_) : time(time_) { } typedef void result_type; template<typename info_t> void operator()(const info_t& info1, const info_t& info2) { const auto& i1 = info1; const auto& i2 = info2; process_info<info_t, Time> (i1,i2, time); } private: Time& time; }; int main() { Info_t i1(10,2); Info_t i2(2,10); int t = 1; auto func = boost::bind( my_functor<int>(t), _1, _2 ); func(i1,i2); return 0; } test.cpp(16): error: expression must have a constant value if ((info1.start < info2.end) && (info2.end > info1.end) && (info1.end < info2.start) ) ^ detected during: instantiation of "void my_functor<Time>::operator()(const info_t &, const info_t &) [with Time=int, info_t=Info_t]" at line 313 of "/home/aniketnp/boost_1_55_0/boost/bind/bind.hpp" instantiation of "void boost::_bi::list2<A1, A2>::operator()(boost::_bi::type<void>, F &, A &, int) [with A1=boost::arg<1>, A2=boost::arg<2>, F=my_functor<int>, A=boost::_bi::list2<Info_t &, Info_t &>]" at line 61 of "/home/aniketnp/boost_1_55_0/boost/bind/bind_template.hpp" instantiation of "boost::_bi::bind_t<R, F, L>::result_type boost::_bi::bind_t<R, F, L>::operator()(A1 &, A2 &) [with R=boost::_bi::unspecified, F=my_functor<int>, L=boost::_bi::list2<boost::arg<1>, boost::arg<2>>, A1=Info_t, A2=Info_t]" at line 48 test.cpp(16): error: this operator is not allowed in a template argument expression if ((info1.start < info2.end) && (info2.end > info1.end) && (info1.end < info2.start) ) ^ detected during: instantiation of "void my_functor<Time>::operator()(const info_t &, const info_t &) [with Time=int, info_t=Info_t]" at line 313 of "/home/aniketnp/boost_1_55_0/boost/bind/bind.hpp" instantiation of "void boost::_bi::list2<A1, A2>::operator()(boost::_bi::type<void>, F &, A &, int) [with A1=boost::arg<1>, A2=boost::arg<2>, F=my_functor<int>, A=boost::_bi::list2<Info_t &, Info_t &>]" at line 61 of "/home/aniketnp/boost_1_55_0/boost/bind/bind_template.hpp" instantiation of "boost::_bi::bind_t<R, F, L>::result_type boost::_bi::bind_t<R, F, L>::operator()(A1 &, A2 &) [with R=boost::_bi::unspecified, F=my_functor<int>, L=boost::_bi::list2<boost::arg<1>, boost::arg<2>>, A1=Info_t, A2=Info_t]" at line 48 test.cpp(16): error: expected a ">" if ((info1.start < info2.end) && (info2.end > info1.end) && (info1.end < info2.start) ) ^ detected during: instantiation of "void my_functor<Time>::operator()(const info_t &, const info_t &) [with Time=int, info_t=Info_t]" at line 313 of "/home/aniketnp/boost_1_55_0/boost/bind/bind.hpp" instantiation of "void boost::_bi::list2<A1, A2>::operator()(boost::_bi::type<void>, F &, A &, int) [with A1=boost::arg<1>, A2=boost::arg<2>, F=my_functor<int>, A=boost::_bi::list2<Info_t &, Info_t &>]" at line 61 of "/home/aniketnp/boost_1_55_0/boost/bind/bind_template.hpp" instantiation of "boost::_bi::bind_t<R, F, L>::result_type boost::_bi::bind_t<R, F, L>::operator()(A1 &, A2 &) [with R=boost::_bi::unspecified, F=my_functor<int>, L=boost::_bi::list2<boost::arg<1>, boost::arg<2>>, A1=Info_t, A2=Info_t]" at line 48 As a workaround, I try to do this, but same error if ((info2.start < info2.end) && (info2.end > info1.end) ) { if ( info1.end < info2.start) //do something } // error is propagated towards inner if loop test.cpp(17): error: expression must have a constant value if ( info1.end < info2.start) ^ detected during: instantiation of "void my_functor<Time>::operator()(const info_t &, const info_t &) [with Time=int, info_t=Info_t]" at line 313 of "/home/aniketnp/boost_1_55_0/boost/bind/bind.hpp" instantiation of "void boost::_bi::list2<A1, A2>::operator()(boost::_bi::type<void>, F &, A &, int) [with A1=boost::arg<1>, A2=boost::arg<2>, F=my_functor<int>, A=boost::_bi::list2<Info_t &, Info_t &>]" at line 61 of "/home/aniketnp/boost_1_55_0/boost/bind/bind_template.hpp" instantiation of "boost::_bi::bind_t<R, F, L>::result_type boost::_bi::bind_t<R, F, L>::operator()(A1 &, A2 &) [with R=boost::_bi::unspecified, F=my_functor<int>, L=boost::_bi::list2<boost::arg<1>, boost::arg<2>>, A1=Info_t, A2=Info_t]" at line 49 test.cpp(17): error: this operator is not allowed in a template argument expression (rest error is the same) ------------------------------------------------------------------------------------------------- Now, if I compile it without " -mmic " flag, then there is no compiler errors. I compile with this : icpc -L/home/aniketnp/tbb42_20140122oss/lib/intel64/gcc4.4 -std=c++11 -I/home/aniketnp/boost_1_55_0 -I/home/aniketnp/tbb42_20140122oss/include test.cpp I dont get any error. It compiles and runs fine. Any thoughts ? Please let me know. -- Thanks and regards, Aniket Pugaonkar

2 1

[utility] prior(it, n) for n being an unsigned type
by Adam Romanek 30 Jun '14

30 Jun '14

Hi! This is a re-post from boost-users mailing list, as I didn't get any response there. I've just finished investigating an issue in my code which led it to an assert/abort in certain cases. It turned out it was caused by the use of boost::prior(it, n) where n was unsigned int with some non-zero value. I found a question [1] on the mailing list back in 2004 which describes this issue. Additionally a solution to this problem was also posted in one of the replies [2]. My question is - why hasn't it made into the repository yet? The current behavior of boost::prior(it, n) when n is unsigned type is far from the one expected by its potential users so I think it should either be properly documented (warned) or fixed immediately. Am I not seeing something? WBR, Adam Romanek [1] http://lists.boost.org/Archives/boost/2004/02/61556.php [2] http://lists.boost.org/Archives/boost/2004/02/61578.php

4 11

[utility][iterator] generator_iterator tests and documentation.
by Daniel James 30 Jun '14

30 Jun '14

Hi, The generator_iterator tests and documentation are in both the utility and iterator modules. There are also some relevant issues in the inspect report for the iterator module: http://boost.cowic.de/rc/docs-inspect-develop.html#iterator

2 1

[iterator] Make operators conditionally defined
by Andrey Semashev 30 Jun '14

30 Jun '14

Hi, I've made this pull request: https://github.com/boostorg/iterator/pull/4 which makes operators defined for iterator_facade conditionally defined depending on the iterator category. As a side effect this change fixes Boost.Graph tests broken by the recent change to boost::next()/prior() [1]. Could someone take a look and merge it? [1] http://lists.boost.org/Archives/boost/2014/06/214788.php

1 0

[fusion] BOOST_FUSION_ADAPT_TPL_STRUCT
by Greg Rubino 29 Jun '14

29 Jun '14

Hello all, I'm trying to do something like this with fusion: struct exists_tag {}; template <typename A> struct unary { type_a m_name; }; template <> struct unary<exists_tag> { type_b m_name; }; BOOST_FUSION_ADAPT_TPL_STRUCT((A), (unary)(A), (type_a)(m_name)); BOOST_FUSION_ADAPT_TPL_STRUCT((), (unary)(exists_tag), (type_b)(m_name)); I'm not sure if I'm way off here, or if there is some way to accomplish this that I'm just not seeing. Here's the error that I get when I try to compile this code: ./include/query_tree.h:122:1: error: template parameters not used in partial specialization: ./include/query_tree.h:122:1: error: ‘Oper’ Repeated 8 times. Any ideas? Thanks, Greg

2 2

function convert() -- do you find it useful?
by Andrzej Krzemienski 29 Jun '14

29 Jun '14

Hi, This is the second time that I have found the following function useful when playing with variants of Optional library: template <typename T, typename U> typename std::enable_if<std::is_convertible<U, T>::value, T>::type convert(U && u) { return std::forward(u); } It performs an implicit conversion from U to T, but you can call it explicitly. [1st] time I needed it to implement the behavior of value_or (described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#optional… ): template <class U> constexpr T optional<T>::value_or(U&& v) const&; Requires: is_copy_constructible<T>::value is true and is_convertible<U&&, T>::value is true. Returns: bool(*this) ? **this : static_cast<T>(std::forward(v)). This needs to be implemented in one expression in C++11, because the function is constexpr, so in the ternary operator, I could either apply no cast and risk unnecessary ambiguity in result type in certain cases, or use a static_cast and bring the explicit conversions in that I didn't want. Function convert() saved the day. [2nd] time was when trying to disable the overload in C++11 using SFINAE, but I didn't want to use enable_if (see a more complete example here: http://akrzemi1.wordpress.com/examples/overloading-enable_if-3/) template <typename U> auto value_or(U const& v) const -> decltype(convert<T>(v)) { if (*this) return this->value(); else return v; } template <typename F> auto value_or(F const& f) const -> decltype(convert<T>(f())) { if (*this) return this->value(); else return f(); } I wanted to check with Boost developers if you find such function convert generally useful (and worth adding somewhere in Boost), or is it just my specific needs. Regards, &rzej

4 6

[regex] [test] Regex auto-link-test problem
by Marcel Raad 29 Jun '14

29 Jun '14

Hi, I'm trying to set up all regression tests on my Windows machine. When I try to execute the test in regex\test\auto-link-test, I get the following error message: ..\..\..\..\b2.exe Jamfile:38: in modules.load ERROR: rule "subproject" unknown in module "Jamfile<[...]\auto-link-test>". [...]/tools/build/src/build\project.jam:311: in load-jamfile [...]/tools/build/src/build\project.jam:64: in load [...]/tools/build/src/build\project.jam:145: in project.find [...]/tools/build/src\build-system.jam:535: in load [...]\tools\build\src/kernel\modules.jam:289: in import [...]\tools\build\src/kernel/bootstrap.jam:139: in boost-build [...]\boost-build.jam:17: in module scope I noticed that the build file is called Jamfile instead of Jamfile.v2, do I have to set Boost.Build to some v1 mode?

3 3

Regression tests broken?
by John Maddock 29 Jun '14

29 Jun '14

For reasons I can't understand, large numbers (almost all actually) of the Math lib tests have just started failing on both master and develop, the error messages all relate to missing object files, for example from a PCH build like this: http://www.boost.org/development/tests/master/developer/output/teeks99-02j-… LINK : fatal error LNK1181: cannot open input file 'C:\local\teeks99-02\j\results\boost\bin.v2\libs\math\test\msvc-12.0\debug\asynch-exceptions-on\link-static\threading-multi\pch_light.obj' Or from common object files that are built with an "obj" rule: http://www.boost.org/development/tests/master/developer/teeks99-02j-win2008… LINK : fatal error LNK1181: cannot open input file 'C:\local\teeks99-02\j\results\boost\bin.v2\libs\math\test\msvc-12.0\debug\asynch-exceptions-on\link-static\threading-multi\compile_test_main.obj' I'm unable to reproduce locally (at least when building in libs/math/test), and strangely not all test runners are showing the issue - though most of them are. Anyone any ideas? Thanks, John.

4 8

Re: [boost] Interest in bit-wise flags?
by Jeffrey Bush 28 Jun '14

28 Jun '14

> > > > > Hi Boost! > > > > I have developed a type-safe bit-wise flags class for my own personal use > > and > > am wondering if it would be of interest for me to submit it as a Boost > > library. > > At the moment it is not ready for submission (code is messy) but I am > > testing > > the waters so I present an overview below. > > * Fully ISO standard C++11 (except for an MSVC version which is > > API-compatible > > except it doesn't support as many an infinite number of flag names) > > * They are type-safe, requiring explicit casts to and from > integers/booleans > > * Supports standard bit-wise operations, and always keep values within > the > > possible set of flags > > * Supports getting the name of a flag and looking up flags by name at > > run-time > > (when a flag is actually multiple-flags it gives something like "A|B") > > * Supports getting an array of all flags at run-time > > > > Now the bad things, which may be a deal-breaker: > > * Because of limitations in C++ the syntax can feel a bit awkward. You > have > > to > > use a macro to define flag-names (which actually creates a class) then > you > > can pass those flag-names as template arguments to the flags. An > example: > > FLAG_NAME(A); > > FLAG_NAME(B); > > FLAG_NAME(C); > > typedef Flags<std::uint8_t, Flag_A, Flag_B, Flag_C>::WithValues<0x01, > > 0x02, 0x04> MyFlags; > > * I also couldn't get around using the ::WithValues nested class > > * I use a set of macros to make this cleaner (e.g. the above could be > > FLAGS(A, B, C)) and once defined there is no more ugliness > > > > Thanks for consideration! > > Jeff > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > > Jeffrey Bush <jeff <at> coderforlife.com> writes: > > I have posted the current (ugly) code online: > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81#file-flags-hpp > > Above that is the even uglier MSCV-specific implementation. > > I focused on function not readability when making it, I understand that it > would take significant work to make it Boost ready. > > Differences from BOOST_BITMASK or lordodinscpplib are that it supports ~ > that is value-constrained (only flips bits that are covered by flags, it > supports names at run-time (converting to and from strings), and it can > default-value then flags with powers of two. > > If those features are undesired, then this class is unnecessary seeing that > those other solutions are significantly simpler or more portable. > > However, looking at those has given me some ideas on how to simplify my > code > and make it possibly work in Clang. > > Jeff > I have updated it, simplifying the design while keeping the same API and provided a simple test program, both available at https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81. It now works fine in all compilers I have tested (MSVC 2010, MSVC 2013, mingw-w64 4.8.2, gcc 4.8.2, clang 3.4). This simplification greatly reduced the amount of code and allowed me to combine the fallback version that doesn't need variadic templates into the main version. I have also made it so the declaration can be inside a class or shared header and the definition elsewhere. This separation was necessary because const non-integral values cannot be defined in classes. Additionally, I have cleaned up the code quite a bit to fit better with Boost standards, although not complete yet (still uses tabs and some lines are longer than 80 characters although most are not). The only difference in API is that you can no longer pre-declare flag name objects or do `typedef Flags<uint8_t, Name1, Name2, Name3>::WithValues<1,2,4> MyFlags` or similar like before, you must use the macro FLAGS()/FLAGS_WITH_VALUES() [which was available before]. I have compiled a very detailed list of differences between BOOST_BITMASK and (BOOST_)FLAGS. The first is an advantage of BITMASK, the second is a draw, and the remainder are advantages of FLAGS. - BITMASK requires an enum or scoped enum to be declared and then the macro to be used, but can entirely within a shared header. FLAGS would be a single-line, or if in a shared header have separate declarations and definitions. Both support being inside classes by having some macro outside the class. - BITMASK supports unlimited flags with less than 2^32 while FLAGS supports at most 32 flags but any underlying integral type. Both could have their limits increased. - BITMASK when used with scoped enums requires full bool casting and does not support the ! operator for checking if any/no flag is set and when used with original enums has some type safety issues (can compare values from different enums directly). FLAGS has the best of both, have strong type safety while also supporting the ! operator and an explicit bool cast (safe-bool). - BITMASK allows (and actually the ~ operator causes) bits that aren't associated with flags to be set while FLAGS prevents these bits from ever being set. This is a numerical safety (I have examples when this would be important). - FLAGS will automatically set the flag-values to powers of two if you want it to, reducing possibility of typos for simple flags while still allowing you to have explicit flag values when necessary (for example, when having pre-defined names for combinations of flags or retaining number-compatibility after dropping a particular flag name). BITMASK always requires you to set the values explicitly. - FLAGS support runtime value-name conversion, allowing something like XML reading/writing using the flag names instead of the numbers, debugging output, user-input parsing, etc. Additionally, BOOST_BITMASK is in boost/detail, does this mean it shouldn't be used outside of Boost? (I have a method of making it so there is no need for a separate declaration vs definition, however it is "ugly" but does work [and the end-user wouldn't have to really know] - it makes each flag-name a static function instead of static-const variable and adds an implicit constructor that takes such a static function and calls it to get the real value which is a static-const local variable). Jeff

1 0

Adding helpful requires macros to the enable_if utility
by paul Fultz 28 Jun '14

28 Jun '14

These following set of macros, I have found very useful in C++: #define BOOST_ERROR_PARENTHESIS_MUST_BE_PLACED_AROUND_THE_RETURN_TYPE(...) __VA_ARGS__>::type #define BOOST_FUNCTION_REQUIRES(...) typename boost::enable_if_c<(__VA_ARGS__), BOOST_ERROR_PARENTHESIS_MUST_BE_PLACED_AROUND_THE_RETURN_TYPE #define BOOST_CLASS_REQUIRES(...) typename boost::enable_if_c<(__VA_ARGS__)>::type #define BOOST_REQUIRES(...) typename boost::enable_if_c<(__VA_ARGS__), int>::type = 0 Which I use like the following For functions: template <class T> BOOST_FUNCTION_REQUIRES(boost::is_arithmetic<T>::value) (T) foo(T t) { return t; } And C++11 functions: template <class T, BOOST_REQUIRES(boost::is_arithmetic<T>())> T foo(T t) { return t; } Class specializations: template <class T, class Enable = void> class A { ... }; template <class T> class A<T, BOOST_CLASS_REQUIRES(is_integral<T>())> { ... }; template <class T> class A<T, BOOST_CLASS_REQUIRES(is_float<T>())> { ... }; It would be nice if these were the added with the enable_if utility with boost. Thanks, Paul

4 3

[quickbook] controlling headers in tables
by Andrzej Krzemienski 27 Jun '14

27 Jun '14

Hi Everyone, Does anyone know if in QuickBook it is possible to create a table without the header row, or to create a table with both header row and a header first column? Regards, &rzej

1 0

[regression][build] Missing tests after the addition of sublibs file
by Adam Wulkiewicz 27 Jun '14

27 Jun '14

Hi, In order to display separated tests for the main and 'spatial index' parts of the Geometry we added a sublibs file to the master branch. The result is that new tests for the main part of the library are missing. I remember the same issue with the develop branch but don't remember how it was fixed. There is probably some collision of names/paths of the old and new tests. Could we do something about it? Could it be fixed by some manual cleanup? Or must the old tests dissapear naturally? Could this be considered as a bug in Build? For convenience: http://www.boost.org/development/tests/master/developer/geometry.html http://www.boost.org/development/tests/master/developer/geometry-index.html Regards, Adam

2 1

dynamically coupling documentation to unit testing
by Roger Martin 27 Jun '14

27 Jun '14

Hi, Been thinking. What I've come to like in documentation is a section at the top of a class or functor that includes some real examples code in the 'doxygen' section that shows how to use. My question is how difficult would it be to make unit testing pick these up and actually run them? If written with unit equalities this would gain by making me and developers write good header examples at the same time as making unit tests and continuously validate documentation isn't getting out-of-date as well. And have the output from the tests be compatible with jenkins or other build system's reporting? How feasible to do this? Is this a possibility to add to boost? Or should it be an llvm based project?

5 5

[align] git update problem
by Fletcher, John P 27 Jun '14

27 Jun '14

I am attempting to update my local copy of boost develop, which I can usually do with the commands: git checkout develop git pull --recurse-submodules git submodule update --init and then git submodule foreach git checkout develop git submodule foreach git pull I have not done this for some time. When I did it today I get a lot of messages from boost align with unmerged files and it will not update. I have not worked on these files myself. What do I need to do to get boost align restored to a good state? Thanks John

2 1

Issue Running Regression Tests on msvc-12.0
by Matthew Musto 27 Jun '14

27 Jun '14

I have been trying to run a regression test against msvc-12 on Windows 8.1 and I am getting the following errors. In the past, this has run fine. I run this command from my cmd prompt: python run.py --runner=Matusi143 --toolsets=msvc-12.0 -tag=master Everything appears to go fine until... Fetching submodule tools/build Fetching submodule tools/inspect Fetching submodule tools/litre Fetching submodule tools/quickbook Already up-to-date. # Executing GIT command: c:\boost_dev\boost_root> git submodule "update" "--init" # Executing GIT command: c:\boost_dev\boost_root> git checkout "master" Already on 'master' Your branch is up-to-date with 'origin/master'. # Executing GIT command: c:\boost_dev\boost_root> git submodule foreach ""git reset --quiet --hard; git clean -fxd"" Entering 'libs/accumulators' error: unknown option `hard;' usage: git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>] or: git reset [-q] <tree-ish> [--] <paths>... or: git reset --patch [<tree-ish>] [--] [<paths>...] -q, --quiet be quiet, only report errors --mixed reset HEAD and index --soft reset only HEAD --hard reset HEAD, index and working tree --merge reset HEAD, index and working tree --keep reset HEAD but keep local changes -p, --patch select hunks interactively Stopping at 'libs/accumulators'; script returned non-zero status. Traceback (most recent call last): File "run.py", line 83, in <module> runner(root) File "c:\boost_dev\tools_regression_src\regression.py", line 264, in __init__ self.main() File "c:\boost_dev\tools_regression_src\regression.py", line 650, in main getattr(self,action_m)() File "c:\boost_dev\tools_regression_src\regression.py", line 604, in command_regression self.command_cleanup() File "c:\boost_dev\tools_regression_src\regression.py", line 274, in command_cleanup self.git_source_checkout(True) File "c:\boost_dev\tools_regression_src\regression.py", line 939, in git_source_checkout self.git_checkout(git_info['boost'], self.git_branch(), clean) File "c:\boost_dev\tools_regression_src\regression.py", line 917, in git_checkout self.git_command( 'submodule foreach', '"git reset --quiet --hard; git clean -fxd"') File "c:\boost_dev\tools_regression_src\regression.py", line 899, in git_command raise Exception( 'GIT command "%s" failed with code %d' % (git_cli, rc) ) Exception: GIT command "git submodule foreach ""git reset --quiet --hard; git clean -fxd""" failed with code 1 c:\boost_dev> Any help is greatly appreciated. -- -------------------- Matthew Musto

4 9

[parameter] #line markers in literate tests
by Edward Diener 27 Jun '14

27 Jun '14

Is there any logical reason for the #line markers in the source files for the 'literal' tests in Boost parameter ? VC++ will not compile these tests with them and although they appear to me as completely valid C++ I would like to create a pull request to fix the VC++ problem. If there is no reason for the #line markers I can remove them, else I can wrap in "#if !defined(BOOST_MSVC)/#endif" pairs after including boost/config.h.

2 2

Boost Build question
by Emil Dotchevski 27 Jun '14

27 Jun '14

Hello, I'm trying to instruct bjam to attempt to output an iphone executable (btw I'm not trying to build Boost itself.) What's the correct way to do this? I apologize if this is explained somewhere, but searching online mostly finds xcode-related information, and the suggestions in the few pages that looked relevant didn't work for me. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

1 0

[utility]Re-assigned tickets
by Niklas Angare 26 Jun '14

26 Jun '14

I just re-assigned these tickets that were incorrectly filed against the regression testing component to the utility library: https://svn.boost.org/trac/boost/ticket/9945 https://svn.boost.org/trac/boost/ticket/9944 https://svn.boost.org/trac/boost/ticket/9925 They are now owned by "no-maintainer". Regards Niklas Angare

1 0

Boost.Python and __slots__
by Matt Calabrese 26 Jun '14

26 Jun '14

Does something special need to be done to setup __slots__ on a class bound via Boost.Python? I can set __slots__ on the class and verify that it can be accessed from python, however I am still able to set members that aren't in the __slots__ list. -- -Matt Calabrese

1 0

How to handle generated html files with modular-boost and GIT?
by Paul A. Bristow 26 Jun '14

26 Jun '14

I've started to proof-read Vladimir Batov's Boost.Convert library and correct a (very few) typos etc. I've had some troublesome experience with building docs with Boost.Math and this is similar (but much smaller). Can experienced GIT users suggest how better to handle the problem of generated files in the /html folder. I've provided below a log of what I've done after a single edit to a Quickbook file. As you will see, there are *new* files (with randomized filenames) html/boost/convert_id274115.html html/boost/convert_id274279.html html/boost/convert_id277698.html html/boost/convert_id277857.html (and also my log file cv_20jun14_1135.log) And all the .html file have been modified. So what do I do? I'd hope just to be able to GIT commit (but there will be added files so "git commit -a") and "git push". (But what about obsolete files like html/boost/convert_id999999.html that should be deleted?) . This seems a muddle, so should we remove the /html folder from GIT using gitignore? However this would mean that users would have to generate the html (and assumes that all the tools like Doxygen and autoIndex are setup right - an unwelcome requirement). And what about .log files - it seems very useful and reasonable to have them live in /doc but be ignored by GIT? Could/Should there be a global entry in top level /modular-boost/.gitignore to exclude all .log files? (I'd also like to put .bat or .sh files to build docs etc here too - there are various options in building and automatically dated log files are nice to have. ) Suggestions on how better to manage this? Paul I:\modular-boost>cd ./libs/convert/doc I:\modular-boost\libs\convert\doc>dir Volume in drive I is Boost Volume Serial Number is FAC6-FCC3 Directory of I:\modular-boost\libs\convert\doc 19-Jun-14 18:07 <DIR> . 19-Jun-14 18:07 <DIR> .. 19-Jun-14 18:07 1,413 00_main.qbk 19-Jun-14 18:07 28 98_ref.qbk 19-Jun-14 18:07 16 99_index.qbk 19-Jun-14 18:07 1,158 acknowledgments.qbk 19-Jun-14 18:07 175 algorithms.qbk 19-Jun-14 18:07 1,729 converters.qbk 19-Jun-14 18:07 17,528 convert_ref.xml 19-Jun-14 18:07 10,730 design_notes.qbk 19-Jun-14 18:07 133 generate-html.sh 19-Jun-14 18:07 2,337 getting_serious.qbk 19-Jun-14 18:07 2,848 getting_started.qbk 19-Jun-14 18:07 <DIR> html 19-Jun-14 18:07 357 index.idx 19-Jun-14 18:07 2,601 introduction.qbk 19-Jun-14 18:07 3,060 Jamfile.v2 19-Jun-14 18:07 1,254 lexcast_converter.qbk 19-Jun-14 18:07 1,228 other.qbk 19-Jun-14 18:07 8,427 performance.qbk 19-Jun-14 18:07 1,789 rationale.qbk 19-Jun-14 18:07 220 references.qbk 19-Jun-14 18:07 1,627 return_value.qbk 19-Jun-14 18:07 5,431 scratchpad.txt 19-Jun-14 18:07 4,372 sstream_converter.qbk 22 File(s) 68,461 bytes 3 Dir(s) 99,253,600,256 bytes free I:\modular-boost\libs\convert\doc>b2 -a --enable-index > cv_20jun14_1135.log I:\modular-boost\libs\convert\doc>git status On branch develop Your branch is up-to-date with 'origin/develop'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: convert_ref.xml modified: html/boost/cnv/adapter.html modified: html/boost/cnv/base.html modified: html/boost/cnv/basic_stringstream.html modified: html/boost/cnv/lexical_cast.html modified: html/boost/cnv/notation.html modified: html/boost/cnv/printf.html modified: html/boost/cnv/spirit.html modified: html/boost/cnv/strtol.html modified: html/boost/throw_on_failure.html modified: html/boost/throw_on_failure_type.html modified: html/boostbook.css modified: html/convert_reference.html modified: html/docutils.css modified: html/header/boost/convert/lexical_cast_hpp.html modified: html/header/boost/convert/parameters_hpp.html modified: html/header/boost/convert/printf_hpp.html modified: html/header/boost/convert/spirit_hpp.html modified: html/header/boost/convert/sstream_hpp.html modified: html/header/boost/convert/strtol_hpp.html modified: html/header/boost/make_default_hpp.html modified: html/index.html modified: html/index/s17.html modified: html/minimal.css modified: html/standalone_HTML.manifest modified: html/the_boost_convert_library/acknowledgements.html modified: html/the_boost_convert_library/better_error_detection.html modified: html/the_boost_convert_library/boost__lexical_cast_based_converter.html modified: html/the_boost_convert_library/boost_convert_performance_overhead.html modified: html/the_boost_convert_library/boost_convert_with_standard_algorithms.html modified: html/the_boost_convert_library/converters.html modified: html/the_boost_convert_library/design_notes.html modified: html/the_boost_convert_library/design_notes/converter_signature.html modified: html/the_boost_convert_library/design_notes/todo_converter_parameter_related_con siderations__explicit__default__globally_set__others_.html modified: html/the_boost_convert_library/design_notes/todo_converter_pluggability.html modified: html/the_boost_convert_library/design_notes/user_interface_signature.html modified: html/the_boost_convert_library/getting_started.html modified: html/the_boost_convert_library/getting_started/basic_error_processing.html modified: html/the_boost_convert_library/getting_started/flexibility_and_adaptability_to_c hange.html modified: html/the_boost_convert_library/introduction.html modified: html/the_boost_convert_library/other_conversions.html modified: html/the_boost_convert_library/performance.html modified: html/the_boost_convert_library/references.html modified: html/the_boost_convert_library/return_value.html modified: html/the_boost_convert_library/std__stringstream_based_converter.html modified: html/the_boost_convert_library/std__stringstream_based_converter/integration_of_ user_defined_types.html modified: html/the_boost_convert_library/std__stringstream_based_converter/locale_support. html modified: html/the_boost_convert_library/std__stringstream_based_converter/the___default_c onstructible__type_requirement.html modified: introduction.qbk Untracked files: (use "git add <file>..." to include in what will be committed) cv_20jun14_1135.log html/boost/convert_id274115.html html/boost/convert_id274279.html html/boost/convert_id277698.html html/boost/convert_id277857.html html/boost/convert_id285317.html html/boost/convert_id285442.html no changes added to commit (use "git add" and/or "git commit -a")

6 8

ptr_vector requiring non-const iterator for insert
by Florian Burkart 26 Jun '14

26 Jun '14

Hi, I noticed that ptr_vector requires a non-const iterator for insert. This is inherited from ptr_sequence_adapter, which defines iterator insert( iterator position, T* x ); Under C++11, this differs from std::vector, which, since C++11, is happy to take const_iterators. iterator insert( const_iterator pos, const T& value ); I read somewhere that C++11 was attempting to clear up some confusion in the standard between iterator constness and container constness. Just wondering whether this should be adopted (e.g. changed) in ptr containers. Gave me an error when I switched from vector to ptr_vector in a drop-in fashion. Not sure whether that is already planned, but google didn't find anything. Florian

2 1

[parameter] 'develop' branch breaks tests with VC++
by Edward Diener 25 Jun '14

25 Jun '14

In testing out potential changes in Boost PP against other Boost libraries, to make sure those changes break no code, I noticed that running tests in the Boost parameter 'develop' branch against VC++ ( msvc-12.0 ) creates a number of compiler errors related to Boost PP. These errors in my tests look odd and I cannot figure out from what source they are happening: ...failed compile-c-c++ ..\..\..\bin.v2\libs\parameter\test\literate\predicate-requirements0.test\msvc-12.0\debug\threading-multi\predicate-requirements0.obj... compile-c-c++ ..\..\..\bin.v2\libs\parameter\test\literate\handling-out-parameters0.test\msvc-12.0\debug\threading-multi\handling-out-parameters0.obj handling-out-parameters0.cpp /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2121: '#' : invalid character : possibly the result of a macro expansion /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_IIF_BOOST_PP_BOOL_0' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : see reference to class template instantiation 'boost_param_params_649f<BoostParameterDummy>' being compiled /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2146: syntax error : missing ',' before identifier 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_required' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'graph' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2059: syntax error : ')' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_TUPLE_EAT_2' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_required': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PARAMETER_FLATTEN_SPEC' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'required': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2143: syntax error : missing ',' before ')' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'vertices': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'get': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'index_map' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'default_color_map': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'num_vertices': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_TUPLE_EAT_4' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'line' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2143: syntax error : missing ',' before 'constant' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2143: syntax error : missing ',' before 'string' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'visitor' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2059: syntax error : ',' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C3861: 'optional': identifier not found /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_FOR_EACH_P' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_FOR_EACH_O' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_FOR_EACH_M' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PARAMETER_FUNCTION_PARAMETERS_M' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2882: 'tag' : illegal use of namespace identifier in expression /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_TAIL_I' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_FOR_EACH_I_P' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_FOR_EACH_I_O' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'BOOST_PP_SEQ_FOR_EACH_I_M' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2977: 'boost::parameter::parameters' : too many template arguments C:\Programming\VersionControl\modular-boost\boost/parameter/parameters.hpp(715) : see declaration of 'boost::parameter::parameters' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2955: 'boost::parameter::parameters' : use of class template requires template argument list C:\Programming\VersionControl\modular-boost\boost/parameter/parameters.hpp(715) : see declaration of 'boost::parameter::parameters' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2146: syntax error : missing ';' before identifier 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_IIF_BOOST_PP_BOOL_0' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2146: syntax error : missing ';' before identifier 'BOOST_PP_IIF_BOOST_PP_BOOL_BOOST_PP_DEC_BOOST_PP_SEQ_SIZE_required' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2899: typename cannot be used outside a template declaration /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2065: 'Args' : undeclared identifier /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2923: 'boost_param_result_649f' : 'Args' is not a valid template type argument for parameter 'Args' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2955: 'boost_param_result_649f' : use of class template requires template argument list /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : see declaration of 'boost_param_result_649f' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2143: syntax error : missing ';' before '{' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2447: '{' : missing function header (old-style formal list?) /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2146: syntax error : missing ',' before identifier 'BOOST_PP_IIF_BOOST_PP_BOOL_' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2993: 'Args' : illegal type for non-type template parameter 'BOOST_PP_IIF_BOOST_PP_BOOL_0' /home/daniel/dev/boost/trunk/libs/parameter/doc/index.rst(649) : error C2988: unrecognizable template declaration/definition If I test against the 'master' branch of parameter these errors do not occur. If I run the tests using gcc these errors do not occur. I believe changes that were made to the 'develop' branch of parameter are causing these errors. Furthermore I do not see these errors in the 'develop'regression tests for parameter, so i am puzzled. Any help would be appreciated.

2 2

[git workflow questions for boost]
by Robert Ramey 25 Jun '14

25 Jun '14

I've discovered a couple of changes I want to see incorporated into some boost libraries. In this particular instance the modules are mpl and tools. The "best" way of doing this for me is to: use github to fork the modules in question clone the modules to my local machine make (and test) my changes push them to the the fork enter a pull request. sometime later delete the fork from github This is well described here https://help.github.com/articles/fork-a-repo So far so good. But I have a couple of questions about this. I currently have modular boost installed on my machine. It seems that I want to: delete the module in question. clone to the same spot I just deleted. do everything above. delete the module again. clone from the original? update super project? rerun b2 headers? what? - I'm sort of at a loss here. I'm sort of uncomfortable with deleting the "official" version - but it seems the right think to do. I would appreciate any observations/advice from some more experienced boosters. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/git-workflow-questions-for-boost-tp46644… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

new Boost.Test in 1.56.0?
by Yanchenko Maxim 25 Jun '14

25 Jun '14

Hi, There were many changes in Boost.Test recently. Will they go to the 1.56.0 release? Thanks, Maxim

1 0

Attempting to Compile on AIX 6.1 with gcc
by Axel Ismirlian 24 Jun '14

24 Jun '14

Hello everyone, I have been attempting to compile the entirety of boost on AIX 6.1 with gcc. Currently, I am compiling for 32-bits. I have had some moderate success by specifying extra flags to the compilation, but some issues persist that may require code change (or simply more explicit linking) and as a result I am at loss of what to do. Here are some of the issues that pop up: ld: 0711-317 ERROR: Undefined symbol: .test_main(int, char**) collect2: error: ld returned 8 exit status ld: 0711-317 ERROR: Undefined symbol: init_unit_test_suite(int, char**) collect2: error: ld returned 8 exit status I think these two are linking issues, but I am not sure how to include the missing files. The first primarily affects boost.asio, but others are affected as well. The second primarily affects boost.conversion. gcc.link ../bin.v2/libs/math/test/test_bessel_k.test/gcc-4.8.1/debug/link-static/test_bessel_k collect2: fatal error: ../bin.v2/libs/math/test/test_instances/gcc-4.8.1/debug/link-static/libtest_instances.a: not a COFF file In the math library I get this issue, and also many floating point constants are being truncated to zero. Is there any way to prevent that? Allocator = std::allocator<long unsigned int>] BOOST_MP_FORCEINLINE BOOST_CONSTEXPR cpp_int_backend() BOOST_NOEXCEPT{} ../boost/multiprecision/cpp_int.hpp:1032:41: note: candidate expects 0 arguments, 1 provided These compilation errors resolve around multiprecision. I don't know how to proceed on this error at all. I am currently compiling with the following command: ../b2 -a "cxxflags=-fpermissive -g" "linkflags=-lpthread -lc128 -Wl,-bbigtoc" Any suggestions or advice is appreciated! Thank you for your time! Sincerely, -Axel

1 0

Boost Social Event at CppCon
by Jon Kalb 24 Jun '14

24 Jun '14

Boosters, Because a lot of Boosters are going to be attending CppCon, we¹d like to arrange a social event for Boosters/C++Now regulars. http://cppcon.org/ If you are planning to attend CppCon or even If you are just going to be in or around Bellevue, Washington between September 7th and 12 and you¹d like to join us for dinner, please let us know so we can get a count. Please send mail to: social(a)boost.org Once we settle on a date, etc, we¹ll let everyone who responded know when and where, so please let us know, even if you are a ³maybe.² This year¹s CppCon program includes sessions from a number of Boosters and C++Now regulars with sessions specifically about Boost Libraries. If you are considering attending, please be aware that the Early Bird registration deadline is just days away. http://cppcon.org/registration/ If you are attending, please make your hotel reservations soon. We are likely to sell out of our room block. http://cppcon.org/lodging/ I hope to see you at CppCon. Jon

1 0

[optional] Warnings about uninitialized values
by Andrey Semashev 23 Jun '14

23 Jun '14

Hi, When I use boost::optional I often see gcc warnings about using possibly uninitialized values. I've seen such warnings in my projects outside Boost but now I encountered them in Boost.Log. Building the current develop with gcc 4.8 I see this: ./boost/date_time/constrained_value.hpp: In member function ‘boost::shared_ptr<boost::log::v2_mt_posix::sinks::sink> boost::log::v2_mt_posix:: {anonymous}::default_text_file_sink_factory<CharT>::create_sink(const settings_section&) [with CharT = wchar_t; boost::log::v2_mt_posix:: {anonymous}::default_text_file_sink_factory<CharT>::settings_section = boost::log::v2_mt_posix::basic_settings_section<wchar_t>]’: ./boost/date_time/constrained_value.hpp:76:7: warning: ‘*((void*)& day +2)’ may be used uninitialized in this function [-Wmaybe-uninitialized] value_ = value; ^ libs/log/src/init_from_settings.cpp:172:32: note: ‘*((void*)& day +2)’ was declared here optional< unsigned short > day; ^ libs/log/src/init_from_settings.cpp:249:87: warning: ‘*((void*)& weekday +4)’ may be used uninitialized in this function [-Wmaybe-uninitialized] return sinks::file::rotation_at_time_point(weekday.get(), hour, minute, second); ^ libs/log/src/init_from_settings.cpp:171:37: note: ‘*((void*)& weekday +4)’ was declared here optional< date_time::weekdays > weekday; ^ I attached the full log for convenience. The code in question is this function: https://github.com/boostorg/log/blob/develop/src/init_from_settings.cpp#L171 Note that at line 248 and below I check that the optional is filled before using it, so there is no way I'll be accessing any uninitialized data (that is, if boost::optional behaves correctly). I suspect this may be a compiler bug. I tried to create a minimal example to reproduce it but the warning doesn't show in a simple context. However, I'd like it to be worked around somehow (unless it's an actual bug in boost::optional). Any suggestions? Am I missing a bug in my code?

3 5

[chrono] stopwatches tests failing
by Marcel Raad 22 Jun '14

22 Jun '14

Hi, currently all the stopwatches tests are failing with fatal error C1083: Cannot open include file: 'boost/chrono/stopwatches/stopwatch.hpp': No such file or directory (on MSVC). Apparently no symlink is created for the newly moved stopwatches subdirectory. Unfortunately I have no idea how to tell Boost.Build to do that.

2 2

How to make bjam use gcc instead of g++ using custom compiling and linking options
by Edson Eustachio 22 Jun '14

22 Jun '14

Due to some environment settings I cannot change, I have to build a lib using bjam instead of make. In my own development environment, I have a Makefile that can successfuly build the lib with the following options: gcc -x c -fPIC -shared -w -I include -o libfmtkit.so -lm src/fm5x.c src/fmTXT.c src/fmAiq.c src/fmArray.c src/fmCalc.c src/fmCandle.c src/fmCT.c src/fmCSI.c src/fmDate.c src/fmDJ.c src/fmFile.c src/fmFin.c src/fmFS.c src/fmPNF.c src/fmStr.c src/fmTc.c src/fmTrade.c src/fmTT.c So, I want to reproduce the options above in a Jamfile The first step is replace g++ by gcc. I've already found this can be done adding the rule using gcc But when I do that I got : $ bjam error: at /usr/share/boost-build/build/project.jam:825 error: duplicate initialization of gcc with the following parameters: error: version = 4.4.3 So, I conclude I am already using gcc instead g++. Is that right? The second step is overwrite the options -fPIC -shared -w to the my Jamfile Below is the Jamfile: lib fmtkit : src/fm5x.c src/fmAiq.c src/fmArray.c src/fmCSI.c src/fmCT.c src/fmCalc.c src/fmCandle.c src/fmChartW.c src/fmDJ.c src/fmDate.c src/fmFS.c src/fmFile.c src/fmFin.c src/fmGraph.c src/fmPNF.c src/fmStr.c src/fmTT.c src/fmTXT.c src/fmTc.c src/fmTrade.c : <include>include : <link>shared; I've passed thru the boost documentation but I've not found or I'm not able to understand how to do that into my Jamfile. Does anyone have some clue of where should I find instructions to setting that? This is the output I get when I try to build the lib using the Jamfile described above: $ bjam...found 81 targets......updating 3 targets... gcc.compile.c bin/gcc-4.4.3/debug/fmChartW.oIn file included from src/fmChartW.c:7: include/fmChartW.h:163: error: expected ')' before 'hdc' include/fmChartW.h:166: error: expected ')' before 'hdc' include/fmChartW.h:175: error: expected ')' before 'hdc' include/fmChartW.h:176: error: expected ')' before 'hdc' src/fmChartW.c:13: error: expected ')' before 'hdc' src/fmChartW.c:300: error: expected ')' before 'hdc' src/fmChartW.c: In function 'fmChartScreenInit': src/fmChartW.c:323: warning: implicit declaration of function 'malloc' src/fmChartW.c:323: warning: incompatible implicit declaration of built-in function 'malloc' src/fmChartW.c:329: warning: implicit declaration of function 'free' src/fmChartW.c:329: warning: incompatible implicit declaration of built-in function 'free' src/fmChartW.c: In function 'fmChartScreenClose': src/fmChartW.c:350: warning: incompatible implicit declaration of built-in function 'free' src/fmChartW.c: At top level: src/fmChartW.c:396: error: expected ')' before 'hdc' src/fmChartW.c:604: error: expected ')' before 'hdc' "g++" -x c -O0 -fno-inline -Wall -g -fPIC -I"include" -c -o "bin/gcc-4.4.3/debug/fmChartW.o" "src/fmChartW.c" ...failed gcc.compile.c bin/gcc-4.4.3/debug/fmChartW.o... gcc.compile.c bin/gcc-4.4.3/debug/fmGraph.o ... src/fmGraph.c:2544: error: 'fmSCALETYPESEMILOG' undeclared (first use in this function) src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2546: error: dereferencing pointer to incomplete type src/fmGraph.c:2547: error: dereferencing pointer to incomplete type src/fmGraph.c:2551: error: dereferencing pointer to incomplete type src/fmGraph.c:2551: error: dereferencing pointer to incomplete type src/fmGraph.c:2551: error: dereferencing pointer to incomplete type src/fmGraph.c:2551: error: dereferencing pointer to incomplete type src/fmGraph.c:2551: error: dereferencing pointer to incomplete type src/fmGraph.c:2551: error: dereferencing pointer to incomplete type src/fmGraph.c:2552: error: dereferencing pointer to incomplete type src/fmGraph.c: In function 'fmGraphYpos': src/fmGraph.c:2565: error: 'fmSCALETYPESEMILOG' undeclared (first use in this function) src/fmGraph.c:2573: error: 'fmSCALETYPEINVERTED' undeclared (first use in this function) "g++" -x c -O0 -fno-inline -Wall -g -fPIC -I"include" -c -o "bin/gcc-4.4.3/debug/fmGraph.o" "src/fmGraph.c" ...failed gcc.compile.c bin/gcc-4.4.3/debug/fmGraph.o......skipped <pbin/gcc-4.4.3/debug>libfmtkit.so for lack of <pbin/gcc- 4.4.3/debug>fmChartW.o......failed updating 2 targets......skipped 1 target... Thanks in advance

1 0

big problem with dependency changes
by Robert Ramey 21 Jun '14

21 Jun '14

Currently the master branch has a few problems. Here is one typical example. My project uses the current master to provide boost libraries which I'm not working on. One file has the statement #include <boost/utility/enable_if.hpp> which fails to compile since boost/utility/enable_if.hpp has been moved to core. This raises a few questions. a) Isn't the master branch always supposed to be working? b) There are a lot of intermediate checkins which break the master. Should these be done an a branch and, once they are believed to be all correct, merged in as a group. This would support the concept a) above. c) will I have to change code in the library I maintain to manually change all occurrences of #include <boost/utility/enable_if.hpp> to #include <boost/core/enable_if.hpp> ? d) Why are the tests on the master branch passing? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/big-problem-with-dependency-changes-tp46… Sent from the Boost - Dev mailing list archive at Nabble.com.

11 27

Efficient tuple implementation
by Louis Dionne 20 Jun '14

20 Jun '14

Hi, I recently discovered (or maybe not) a neat trick to implement a tuple-like container. The technique has a couple of drawbacks which I will explain later. For a real example, you can see my list implementation in Boost.Hana at [1]. Here's the idea: auto list = [](auto ...xs) { return [=](auto access) { return access(xs...); }; }; auto head = [](auto xs) { return xs([](auto first, auto ...rest) { return first; }); }; auto tail = [](auto xs) { return xs([](auto first, auto ...rest) { return list(rest...); }); }; auto length = [](auto xs) { return xs([](auto ...z) { return sizeof...(z); }); }; // etc... // then use it like auto three = length(list(1, '2', "3")); The idea is to use the capture of the lambda as a fast compiler-generated struct with the desired members. By passing a function to that lambda, we get an access to the unpacked representation of those members and we can then apply any fast algorithm on parameter packs. Drawbacks --------- 1. The type of that tuple is completely opaque. Hence, it is harder to debug, but I'm working on other stuff that should make this a moot point. 2. Since lambdas can't be made constexpr, this tuple can't either. However, there was some discussion about proposing constexpr lambdas at C++Now and it looked like there was a lot of support for the idea, so this might change. Benchmarks ---------- I ran a couple of benchmarks testing the compilation time and the results are self explanatory. The benchmark suite is at [2]. ## Create a tuple of n elements The test code looks like: #include <boost/tuple/tuple.hpp> int main() { auto go = boost::make_tuple(1, ..., n); } <a href="http://imgur.com/rKqmvk3"><img src="http://i.imgur.com/rKqmvk3.png"/></a> ## Access the last element of a tuple of n elements The test code looks like: #include <boost/tuple/tuple.hpp> int main() { auto go = boost::make_tuple(1, ..., n); auto last = boost::get<n-1>(go); } <a href="http://imgur.com/b4rWR4y"><img src="http://i.imgur.com/b4rWR4y.png"/></a> Also, for those following the development of Boost.Hana, it is going well and I am preparing for a followup in the near future. Stay tuned! Regards, Louis Dionne [1]: http://github.com/ldionne/hana/blob/master/include/boost/hana/list.hpp [2]: http://github.com/ldionne/benchcc/tree/master/benchmarks

9 22

[optional] Add Optional to BoostBook subset of Boost C++ Libraries
by Andrzej Krzemienski 20 Jun '14

20 Jun '14

Hi, I am looking at this documentation index: http://www.boost.org/doc/libs/develop/doc/html/index.html And I can see that Optional is not included. Could someone add it there, or is there any criterion why certain libraries don't make it in? Regards, &rzej

3 2

[interprocess] Ticket 9414 (32 process communicating with 64 process)
by Joseph Van Riper 20 Jun '14

20 Jun '14

I ran into a problem with message queues that, after a couple of days investigation, lead to finding this bug. I notice that the maintainer has labelled this bug as 'invalid'. I would like to convince the maintainer otherwise. My alternatives are less optimum. I am working on a project where, on a Windows machine, I am running a service that waits for messages on the message queue. On a 32-bit environment, I will not run into any problems. But in a 64-bit environment, I may have either 64-bit or 32-bit clients attempting to write to the message queue, due to the nature of my needs and the nature of the Windows operating system. The messages from the clients are not specific to the bit-ness of the client, but are sent to the server. The server records these messages to a database it maintains. The server then pulls messages from the database and posts it to a web page. As the code stands now, I will have to compile both a 32-bit and 64-bit version of the server to install on 64-bit WinOS boxes, maintaining two separate databases of similar information, which will post to the web site with no sense of co-ordination (and little hope of co-ordination since they can't talk to each other). Or, alternatively, I would have to create my own message queue that doesn't rely upon std::size_t, but perhaps uses boost::uint32_t or boost::uint64_t instead... but it seems silly to me to maintain another message queue when this one is very close to being able to do what I need. I should also point out that I need for this to work in Linux as well, although I don't expect Linux has the Windows annoyance of having to work with two different bit-wise operating systems on one box. At the very least, I'd like a dialog, so I can understand why this defect is considered 'invalid'. Convince me that it really is invalid, and I'll go away. Otherwise, I respectfully argue against it. - Trey

3 4

blincubator comments
by Sohail Somani 19 Jun '14

19 Jun '14

Hi Robert, First of all, great idea and thanks for doing it. The concepts are solid and the site will be a great help for users and authors alike. It appeared that it was not possible to add any reviews anonymously. Is this by design? Does one have to register? It would be clearer if the page was unavailable or that there was a placeholder requiring the visitor to register before they could view the "submit review" page[1]. I closed the page after writing a review and being unable to submit because it seemed the site was buggy and so I set out to submit a report, but maybe the mistake was that I was supposed to have registered first. It was unclear. Also, if you ever do consider writing another version, consider Django because the admin interface[2] could allow you to generate a nice interface without futzing around with plugins and can also help you create a more maintainable site because it forces you into a structure. I'd be happy to help if you choose to go this way. General question: are there any other sites/applications of this kind out there? It seems to be a generally useful thing to make it easier to solicit user contributions for open source software. The closest would be a fork+pull request in Github that people can comment on. Maybe that's enough, I don't know. [1] http://rrsd.com/blincubator.com/review/?library_post_id=769 [2] http://www.djangobook.com/en/2.0/chapter06.html Sohail

3 4

[interest] Is there interest in planar angle library ?
by Matus Chochlik 19 Jun '14

19 Jun '14

On Tue, Jun 17, 2014 at 11:52 PM, Robert Ramey <ramey(a)rrsd.com> wrote: > how would this differ from boost units? > For one thing, in its dependencies, Boost.Units is a wonderful library, but for many use-cases it is too heavyweight. As mentioned before this library depends only on standard cmath. Also this library is more specialized on angle operations than Boost.Units is, at least out of the box. Matus

2 2

[gil] Optimizations
by Harg Tholan 19 Jun '14

19 Jun '14

Hi all, I've been wondering whether is there any room for ASM optimizations in GIL. Regards, H4rg.

2 1

[modularization] spirtit -> serialization
by Vicente J. Botet Escriba 19 Jun '14

19 Jun '14

Hi, comments about this dependency: |<boost/serialization/vector.hpp>| * from |<boost/spirit/home/support/detail/lexer/serialise.hpp>| It seems that this file is not used |boost/spirit/home/support/detail/lexer/serialise.hpp Could this file be removed or moves to examples? Best, Vicente |

10 58

Interest in bit-wise flags?
by Jeffrey Bush 19 Jun '14

19 Jun '14

Hi Boost! I have developed a type-safe bit-wise flags class for my own personal use and am wondering if it would be of interest for me to submit it as a Boost library. At the moment it is not ready for submission (code is messy) but I am testing the waters so I present an overview below. * Fully ISO standard C++11 (except for an MSVC version which is API-compatible except it doesn't support as many an infinite number of flag names) * They are type-safe, requiring explicit casts to and from integers/booleans * Supports standard bit-wise operations, and always keep values within the possible set of flags * Supports getting the name of a flag and looking up flags by name at run-time (when a flag is actually multiple-flags it gives something like "A|B") * Supports getting an array of all flags at run-time Now the bad things, which may be a deal-breaker: * Because of limitations in C++ the syntax can feel a bit awkward. You have to use a macro to define flag-names (which actually creates a class) then you can pass those flag-names as template arguments to the flags. An example: FLAG_NAME(A); FLAG_NAME(B); FLAG_NAME(C); typedef Flags<std::uint8_t, Flag_A, Flag_B, Flag_C>::WithValues<0x01, 0x02, 0x04> MyFlags; * I also couldn't get around using the ::WithValues nested class * I use a set of macros to make this cleaner (e.g. the above could be FLAGS(A, B, C)) and once defined there is no more ugliness Thanks for consideration! Jeff

5 5

Boost Library Incubator recommended by steering committee
by Beman Dawes 18 Jun '14

18 Jun '14

The Boost Library Incubator (www.blincubator.com) is a web site conceived, designed, and implemented to alleviate the log-jam of libraries waiting to be reviewed by Boost. It helps new library submitters through the process, encourages development of an initial user base, and accumulates feedback in the form of comments, test results and Boost style reviews. The Boost Steering Committee has voted to recommend using the Boost Library Incubator as a prelude to getting a library reviewed by Boost. The Steering Committee recommends libraries currently in the Boost review queue be added to the Incubator by their developers. The relationship between Boost and the Incubator is purely informal, but there as several things Boosters can do to help make the Incubator a success. Authors can submit their libraries and respond to feedback. Users can experiment with submitted libraries and provide feedback on their experience. WordPress/php developers can contribute enhancements to the Boost Library Incubator implementation. The steering committee extends its thanks to Robert Ramey for launching the Boost Library Incubator! --The Boost Steering Committee

5 7

[modularization] Missing libs/core file
by Vicente J. Botet Escriba 18 Jun '14

18 Jun '14

Hi, I don't reach to get the last changes in libs/core after un update of the whole boost repository and it modules cd modular-boost git checkout master git pull git submodule update viboes$ pwd /Users/viboes/github/modular-boost/libs/core viboes$ ls What I need to do to see this new repository? Vicente

9 17

[1.56][multi_index][Sandia-intel-11.1] help with SIGSEVs
by Joaquin M Lopez Munoz 18 Jun '14

18 Jun '14

[I have previously posted to boost-testing to no avail] Hi, Boost.MultiIndex is all green on master except for these two tests with Intel 11.1 on Darwin: http://tinyurl.com/keofovz http://tinyurl.com/muhtnn2 which build fine but exit with code 139 (seg fault) on execution. Could someone with access to this environment trace the error down to more useful information such as the offending line, valgrind backlog or something? Thank you in advance, Joaquín M López Munoz Telefónica

1 0

[interest] Is there interest in planar angle library ?
by Matus Chochlik 17 Jun '14

17 Jun '14

Hi, I would like to gauge interest in adding a very lightweight library implementing a class for handling planar angles and related operations to Boost. The library sources and several examples of usage can be found here: https://github.com/matus-chochlik/angle It does not conform to Boost conventions yet, nor is there any documentation, but the library is very simple to use: There is a template angles::angle<T> representing planar angles, using type T to store the angle value in radians. Conversions for 10 common angle units are included and new units can easily be added. The library also implements construction functions and user-defined literal operators allowing to specify angles in various units and also implements overloads of functions like sin, cos, etc. The only external header that this library includes is standard `cmath`. Here follow some examples of usage: using namespace angles; for(angle<double> a; a < 4_turns; a += 45_deg) { std::cout << a.to<unit::degree>() << std::endl; } for(angle<double> a=-quarters(2); a <= quarters(2); a += gradians(50)) { std::cout << a.to<unit::turn>() << std::endl; } for(angle<double> a; a < turns(1); a += degrees(15)) { std::cout << sin(a) << std::endl; } assert(turns(1) == quarters(4)); assert(degrees(90) == gradians(100)); assert(degrees(45) == quarters(0.5)); assert(degrees(2) == minutes(120)); assert(minutes(4) == seconds(240)); assert(degrees(1) == seconds(3600)); assert(turns(0.5) == gradians(200)); assert(pi(1) == quarters(2)); assert( 3_o_clock == 90_deg); assert( 6_o_clock == 200_gon); assert( 7_o_clock == 210_deg); assert( 9_o_clock == 300_gon); assert(11_o_clock == 1_turns - 30_deg); assert(12_o_clock == 2_pi); Please let me know if you are interested in the 'Boostification' of this library or if you have any ideas on how it could be improved. Best regards, Matus

3 2

[bcp] Option for inlining namespace boost
by Anton Bikineev 17 Jun '14

17 Jun '14

Hi all, I know it is possibly a very specific case, but is it possible for bcp to make namespace boost as inline? Thanks.

1 0

[accumulators] broken on msvc
by Jürgen Hunold 17 Jun '14

17 Jun '14

Hi! It seems that Boost.Accumulators is broken for all msvc builds with error messages like: boost/accumulators/framework/accumulators/reference_accumulator.hpp(72) : error C2061: syntax error : identifier 'BOOST_PP_CAT' boost/accumulators/framework/accumulators/reference_accumulator.hpp(72) : fatal error C1903: unable to recover from previous error(s); stopping compilation (from http://www.boost.org/development/tests/develop/developer/output/teeks99-02e…) The regression page http://www.boost.org/development/tests/develop/developer/accumulators.html shows _all_ msvc builders failing. My own code broke with an identical message sometime last week. Any ideas? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

5 10

clang toolset on mingw passes -mthreads instead of -pthread
by Peter Dimov 16 Jun '14

16 Jun '14

Can someone who is familiar with Boost.Build please look at the Clang toolset and figure out how can it be persuaded to use the correct -pthread option instead of -mthreads under Windows/MinGW?

3 3

[Modularization] Variant -> Math and the Serialization issue
by Stephen Kelly 16 Jun '14

16 Jun '14

Hello, In regard to the other thread on the subject, I take the position that it should not be a problem for a module to depend on the serialization module. I also take the position that there should not be an explosion of 'serialization foo' modules. That is why I propose reducing the dependencies of serialization, so that depending on serialization is not a problem. That is why I suggested removing the dependency serialization -> spirit The improvement resulting from that is shown here: http://www.steveire.com/boost/deps-june-14/serialization.png http://www.steveire.com/boost/after-edge-removal-june-14/serialization.png So, now we need to remove the dependencies of the second graph. I draw your attention to the following dependencies: serialization ->variant variant -> math math -> [lots of stuff] If the variant -> math edge is removed, we get this: http://www.steveire.com/boost/june-15-serialization-no-variant-math.png http://www.steveire.com/boost/june-15-serialization-no-variant-math.dot which is already a significant improvement. There may be more low hanging fruit remaining. Variant depends on math for a single metafunction. boost::math::static_lcm Can something be changed to make Variant not depend on Math? Thanks, Steve.

5 5

[thread] Promote detail::invoke
by Agustín K-ballo Bergé 16 Jun '14

16 Jun '14

Boost.Thread has a great implementation of `invoke` in it's detail namespace. I would like to see this moved outside of Threads, so that other libraries can benefit from it (or course, only if Vicente thinks this is ok). This seems like an ideal candidate for the Detail submodule, as several other libraries have a need for this piece of functionality. The implementation relies on `BOOST_THREAD_[RV|FWD]_REF`, which could be replaced by `BOOST_[RV|FWD]_REF`. This would mean introducing a dependency on Boost.Move, but I'll leave those details to the people leading the modularization effort. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

2 2

[range] concept checks break chained range adaptors
by Jürgen Hunold 15 Jun '14

15 Jun '14

Hi Neil, the fix for #9851 broke some of our code. We use chained range adaptors like std::vector<std::string> separated std::set<Foo> foos; boost::copy(separated | boost::adaptors::transformed(boost::bind(Foo::fromString, _1)) | boost::adaptors::filtered(boost::bind(&Foo::isValid, _1)), std::inserter(foos, foos.end())); which fails with error: constructor for 'boost::transform_iterator<boost::_bi::bind_t<Foo, Foo (*)(const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > &), boost::_bi::list1<boost::arg<1> > >, std::__1::__wrap_iter<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > *>, boost::use_default, boost::use_default>' must explicitly initialize the member 'm_f' which does not have a default constructor transform_iterator() { } Full testcase and error message attached. This compiles and works with 1.55.0. git bisect shows that this fails to compile from 5f2560f - Ticket 9851 - adaptors should perform concept check assertions. for gcc and for clang starting with e43796c - allow clang to use Range Concepts despite reporting GCC 4.2. msvc-12.0 fails, too. gcc-4.8.2 and clang-3.5 (trunk) for the record. Any chance to get this fixed for 1.56.0 ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 4

New dependency report
by Peter Dimov 15 Jun '14

15 Jun '14

I've taken care of the mpl -> detail detail -> iterator utility -> iterator critical dependencies, which improved things a bit. The new report is at http://www.pdimov.com/tmp/report-6d1f271/module-overview.html http://www.pdimov.com/tmp/report-6d1f271/module-levels.html It includes reverse dependencies for each module and has been generated from the develop branch of the super-project.

13 115

[Modularization] Dependency diagrams
by Stephen Kelly 15 Jun '14

15 Jun '14

Hello, I have uploaded dependency diagrams for all boost libraries here: http://www.steveire.com/boost/deps-june-14/ The following incidental modules exist: incidentalModules["mpl"] = ("mpl", "type_traits", "typeof", "utility") incidentalModules["math"] = ("math", "lexical_cast") incidentalModules["spirit"] = ("spirit", "pool", "thread", "date_time", "serialization", "chrono", "interprocess") incidentalModules["graph"] = ("graph_", "disjoint_sets", "bimap", "property_map", "mpi", "graph_parallel") incidentalModules["scope_exit"] = ("scope_exit", "local_function") incidentalModules["range"] = ("range", "algorithm", "tr1", "random") The "incidental spirit" module and the "incidental range" modules are problematic. When the serialization->spirit range->algorithm edges are removed, they cease to exist as incidental modules, and the dependency graphs simplify: http://www.steveire.com/boost/after-edge-removal-june-14/ Compare: http://www.steveire.com/boost/deps-june-14/assign.png http://www.steveire.com/boost/after-edge-removal-june-14/assign.png http://www.steveire.com/boost/deps-june-14/range.png http://www.steveire.com/boost/after-edge-removal-june-14/range.png There are obviously more edges that can be investigated, but I recommend addressing serialization->spirit range->algorithm as a priority for now to remove those incidental modules. The "incidental mpl" module is not a priority problem, because anything which depends on the "incidental mpl" module mostly also depends on its dependencies. So, transitively speaking, it is mostly not a problem. It would be nice to resolve it a bit, but it does not need to be a priority. http://www.steveire.com/boost/deps-june-14/mpl.png The "incidental graph" module is not a priority problem because few other modules depend on any of it (only numeric_odeint). So, transitively speaking, it is mostly not a problem. It would still be nice to resolve it a bit to affect the modules inside the closure, but it does not need to be a priority. http://www.steveire.com/boost/graph-rdeps-june-14.png The "incidental scope_exit" module is being addressed afaiu, but it is also not a problem, transitively speaking. Nothing depends on either of them. Thanks, Steve.

2 1

[boost.test] Invoking test case from within another case
by Philip Bennefall 14 Jun '14

14 Jun '14

Hi all, I have built a performance measurement template function that can measure the time that a given piece of code takes to run, as well as provide some statistics such as standard deviation over x iterations etc. I am looking to integrate this into my existing boost.test setup, in a new suite called performance. This works fine if I write new test cases inside the performance test suite that invoke this function, but my goal is to also be able to run preexisting test cases in other suites to measure their performance. It'd be a bit hacky to have to include them again inside the new namespace. Is there a way to invoke a test in a specific test suite from inside another test case? Kind regards, Philip Bennefall

1 0

How do I download module Core?
by Andrzej Krzemienski 14 Jun '14

14 Jun '14

Hi, I can see that module Core is already available on branch Master. But when I try to pull the sources from GitHub (with 'git pull --rebase') it doesn't show up in my clone. Do I need to do anything to see it? Regards, &rzej

5 10

[modular] Re: [regression] Test results unavailable
by Rene Rivera 13 Jun '14

13 Jun '14

It's broken.. Don't know why though. Perhaps the recent code moves have made the testing tools not compile? On Fri, Jun 13, 2014 at 3:04 PM, Adam Wulkiewicz <adam.wulkiewicz(a)gmail.com> wrote: > Hi, > > I noticed that the results are unavailable. Was this planned or is > something broken? > > Regards, > Adam > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

[regression] Test results unavailable
by Adam Wulkiewicz 13 Jun '14

13 Jun '14

Hi, I noticed that the results are unavailable. Was this planned or is something broken? Regards, Adam

1 0

[random] new threefry random engine
by Thijs van den Berg 13 Jun '14

13 Jun '14

Hi all, I've completed a nice new random engine that I would like to propose for addition to boost/random. The engine is called "threefry" and it's based on the paper "Parallel random numbers: as easy as 1, 2, 3" by Salmon, John K. and Moraes, Mark A. and Dror, Ron O. and Shaw, David E. I've been using it myself a lot for the last couple of years, and now I've rewritten it so that it will fit in the boost random framework and adhere to the concepts. It has some really nice properties, in particular for large scale parallel computing: * High quality randomness (according to the BigCrush tests) with a cycle length of 2^258 * Fast (comparable to Mersenne Twister) & little memory usage (13x 64 bit integers) * O(1) discard and guarantees for non-overlapping sequences when the (up to 256 bit) seeds are unequal I've uploaded the code, description and tests to https://github.com/sitmo/threefry The actual engine is at https://github.com/sitmo/threefry/blob/master/random/include/boost/random/t… I would really appreciate any feedback about the idea for inclusion and of course comments about the quality of the code,tests,docs kind regards, Thijs Sitmo Consultancy B.V. Financial Modelling & Data Science + 31 6 24110061 thijs(a)sitmo.com P.O. Box 1059, 2600BB, Delft, The Netherlands

10 60

Errors Compiling in AIX 7.1 with gcc
by Axel Ismirlian 13 Jun '14

13 Jun '14

Hello, I am trying to compile boost on AIX 7.1 with gcc, but I am getting several errors. The configuration checks report that zlib support is disabled even though I do have that package installed. I also don't have icu support. Is there a package for that in AIX? I was not able to find one. Performing configuration checks - symlinks supported : yes - 32-bit : yes - arm : no - mips1 : no - power : yes - lockfree boost::atomic_flag : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : yes - icu : no - icu (lib64) : no - x86 : no - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - zlib : no I also tried adding a user-config.jam in the boost/ (the same place as the project-config.jam) in order to add some flags to my gcc compilation and to use mpi, but my jam was soundly ignored. However, the most concerning of these errors is some apparent assembler error. gcc.compile.asm bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi/asm/make_ ppc32_sysv_xcoff_gas.o Assembler: /tmp//cc0uhEhf.s: line 5: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 8: 1252-016 The specified opcode or pseudo-op is not valid. Use supported instructions or pseudo-ops only. /tmp//cc0uhEhf.s: line 11: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 15: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 19: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 22: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 25: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 27: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 28: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 30: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 32: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 34: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 37: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 40: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 46: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 48: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 50: 1252-142 Syntax error. /tmp//cc0uhEhf.s: line 53: 1252-142 Syntax error. I'm not sure how to go about fixing that. When I go to my /tmp/ directory ccvhH2Fc.s is not an assembler file present. Right after this message another error appears. ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi /asm/jump_ppc32_sysv_xcoff_gas.o... gcc.compile.c++ bin.v2/libs/context/build/gcc-4.8.1/release/link-static/threading-multi/untested. o libs/context/src/untested.cpp:7:2: error: #error "! code for this platform is untested - please r emove this file from build/Jamfile.v2 and report the test-result on boost-track !" #error "! code for this platform is untested - please remove this file from build/Jamfile.v2 and report the test-result on boost-track !" What is the complete path for the Jamfile.v2 that this error refers to? Any advice the community can offer would be greatly appreciated. Sincerely, -Axel

2 1

[thread] Mass test failures on clang
by Andrey Semashev 13 Jun '14

13 Jun '14

Hi, I'm seeing mass test failures in Atomic and Log both in develop and master. E.g.: http://www.boost.org/development/tests/develop/developer/atomic.html http://www.boost.org/development/tests/master/developer/atomic.html The logs are not descriptive (as usual) but point to Thread compilation: http://www.boost.org/development/tests/develop/developer/output/teeks99-04b… Could this be resolved? The freeze deadline is nearing, so I'd like to see my test results at least once before it is reached.

4 12

Code review for bug no. 7396
by ullas srinivas 13 Jun '14

13 Jun '14

Hi, I have fixed bug no. 7396 Bug # 7396 :filesystem::path::remove_all(path, error_code) throws filesystem_error exception Description : Several methods in filesystem::path, including remove_all, have an overload in which an extra error_code& argument is taken. According to the docs, this is supposed to cause failure (other than failure to allocate storage) to be reported in the error_code rather than as a thrown filesystem_error exception. However, remove_all can still throw filesystem_error exceptions because it uses a directory_iterator internally but makes no attempt to catch exceptions thrown by it. For example, if a subdirectory is deleted by another thread or process just before remove_all tries to list its contents, directory_iterator_construct will throw a filesystem_error that propagates up to remove_all's caller. As a side note, I think path and directory_iterator are both excessively exception-happy. It makes them painful to use. Root Cause : The exceptions thrown by fs::directory_iterator were not handled in remove_all_aux function of operations.cpp file. Fix: The exceptions thrown by fs::directory_iterator are handled by catching the exception and proper ly assigning error values . Try-catch statement has been put inside remove_all_aux function of operations.cpp file. I kindly request you to please find the patch file attached and review the bug Regards Ullas

1 0

[test] Compilation errors on MinGW 4.8.1
by Adam Wulkiewicz 12 Jun '14

12 Jun '14

Hi, When I try to compile Boost.Test (develop) tests or any other tests using execution_monitor on MinGW-GCC 4.8.1 I get the following errors: ..\..\../boost/test/execution_monitor.hpp:364:27: error: 'FE_DIVBYZERO' was not declared in this scope BOOST_FPE_DIVBYZERO = FE_DIVBYZERO, ^ ..\..\../boost/test/execution_monitor.hpp:365:27: error: 'FE_INEXACT' was not declared in this scope BOOST_FPE_INEXACT = FE_INEXACT, ^ ..\..\../boost/test/execution_monitor.hpp:366:27: error: 'FE_INVALID' was not declared in this scope BOOST_FPE_INVALID = FE_INVALID, ^ ..\..\../boost/test/execution_monitor.hpp:367:27: error: 'FE_OVERFLOW' was not declared in this scope BOOST_FPE_OVERFLOW = FE_OVERFLOW, ^ ..\..\../boost/test/execution_monitor.hpp:368:27: error: 'FE_UNDERFLOW' was not declared in this scope BOOST_FPE_UNDERFLOW = FE_UNDERFLOW, ^ ..\..\../boost/test/execution_monitor.hpp:370:27: error: 'FE_ALL_EXCEPT' was not declared in this scope BOOST_FPE_ALL = FE_ALL_EXCEPT, ^ When I use MinGW-GCC 4.8.0 shipped with Qt5 everything is ok. I though I'll let you know since AFAIS this toolset isn't tested. If you decided to take a look at this and needed a guinea pig I'd be here. Regards, Adam

3 6

Building Boost on Haiku
by Andrew Hudson 12 Jun '14

12 Jun '14

Hi, New booster here. I am building Boost 1.55 on Haiku X86 and have a build issue: -pthreads is not recognized by GCC 4.8 on Haiku X86 and gives an error. pthreads are supported by Haiku by default, so I need to suppress the compiler option but enable pthreads in the build. I used ./bootstrap.sh -PREFIX to set the default lib path as /usr is not used in Haiku Then I started the build with ./b2 install Where and how can I make this config change? I have little jam experience. I also need to suppress use of MPI as this is not ported yet. Many thanks!

1 0

Meeting C++ Schedule released
by Jens Weller 12 Jun '14

12 Jun '14

Hello C++ & Boost Community, since last week the schedule for Meeting C++ is released: http://meetingcpp.com/index.php/schedule14.html Like last year Meeting C++ will feature 21 Talks in 3 Tracks, the conference will be opened by Scott Meyers, the closing Keynote will be given by Hartmut Kaiser. This years Theme Track is "Scientific Programming with C++". Also, if your are a student, you have the chance to participate in our student program which will give 50 Students access to the conference: http://meetingcpp.com/index.php/newsreader/items/meeting-cpp-2014-the-stude… kind regards, Jens Weller

1 0

[config] config_test fails on g++ 4.8/4.9
by Peter Dimov 12 Jun '14

12 Jun '14

... due to In file included from ../libs/config/test/config_test.cpp:376:0: ../libs/config/test/boost_no_lambdas.ipp: In function ???int boost_no_cxx11_lambdas::test()???: ../libs/config/test/boost_no_lambdas.ipp:21:4: error: expected primary-expression before ???void??? (void)[](){}; ^ ../libs/config/test/boost_no_lambdas.ipp:21:4: error: expected ???)??? before ???void??? I'm not sure why.

3 5

[review] Convert library
by Jeroen Habraken 12 Jun '14

12 Jun '14

Hi, As promised my review of the boost::convert library. Note that the questions were answered in a seemingly random order, thus I hope it all comes together. Secondly, being the author of the boost::coerce library [2][3] I may be a little biased at times, please forgive me. -- What is your evaluation of the design? There are two parts to this, the design of the backend and the design of the interface that the user predominantly sees. I have little to say on the first, the notion of multiple backend converters is a big step forwards and their interface is sane. I'm far less convinced when it comes to the user-facing interface as I believe the simple tasks should be simple and intuitive, whereas the harder tasks may be harder. The most trivial use of boost::convert, and boost::lexical_cast and boost::coerce simply don't compare in my opinion. boost::cstringstream_converter cnv; int i = boost::convert<int>::from("23", cnv).value(); versus int i = boost::lexical_cast<int>("23"); int j = boost::coerce::as<int>("23"); When the convert library makes it into boost I'd want to mentally deprecate lexical_cast as a library I should use, and always use convert instead. This means convert should have a default converter, which may well be backed by lexical_cast with an interface such as: int i = boost::convert<int>::from("23").value(); This still doesn't completely satisfy me as I'd like to write int i = boost::convert<int>::from("23"); but it'd be an improvement in my opinion. Now I'm aware lexical_cast doesn't have a non-throwing interface, and it probably never will, but I've solved the problem as follows in boost::coerce: int i = boost::coerce::as_default<int>("XXX"); int j = boost::coerce::as_default<int>("XXX", tag::hex()); int k = boost::coerce::as_default<int>("XXX", 23); int l = boost::coerce::as_default<int>("XXX", tag::hex(), 23); The former two returning the default-constructed int, 0, the latter two returning 23. That said, I'll be the first to admit the coerce interface isn't perfect, the fact that I need SFINAE to distinguish between as_default calls with two parameters, the second either being a tag (somewhat similar to your converters but not quite) or the default value goes to show just that. However I'd prefer int i = boost::convert<int>::from("23", cnv); int i = boost::convert<int>::from_default("23", cnv, 0); to the current interface using value_or(0). This is subjective though, and quite possibly a matter of taste. In summary, before this turns into too long a rant, I think the current user-facing interface can be improved substantially, but I'm well aware this is subjective. -- What is your evaluation of the implementation? I've only had a quick glance at the code and it still looks fine. The gripe I had two years ago regarding the use of reserved names (include guards prefixed with "__") has been fixed. A few comments though: In the boost::lexical_cast based converter there is a try { } catch (...) { } which I believe to be an overly broad catch as lexical_cast explicitly throws a boost::bad_lexical_cast. If in an unlikely event a std::bad_alloc were to be thrown for example I'd rather not have boost::convert hide it from me. In the std::strtol based converter errno isn't checked, and it must be noted that strtol accepts leading whitespace which may or may not be wanted. I've implemented what I believe to be a correct converter using strtol which checks for the leading whitespace in [0], but it comes with no guarantees as it's quite tricky indeed. The new C++11 wrapper std::stol and friends in [1] may be of use here, but unfortunately they only have a throwing interface. All converters are added to the main boost namespace which is crowded enough as it is -- hi boost::_1 --, and libraries should add their functionality to their own namespaces in my opinion. With the current design it's not possible to add them in the boost::convert namespace but I believe they should be in their own namespace, may I suggest boost::converter. It must be said that the first two comments are minor at best, the last regarding the namespace is more important but potentially quite trivial to fix. -- What is your evaluation of the documentation? I've found it to be very hard to write documentation as the library author as at some point you're so intimately familiar with your library that it's hard to get a feel for what the user needs. Whilst there are some rough edges I think the current documentation is decent enough for it not to pose a problem. Again a few comments: The motivation should probably be addressed first, not near the end. The printf and std::strtol based converters aren't documented, and the converters should probably be grouped into a sub-section along with an explanation of how to write your own. Last of all I'd like to see an examples directory showing the examples from the documentation, you already have a test/encryption.hpp which probably belongs there. -- What is your evaluation of the potential usefulness of the library? In the previous review I've argued the library its functionality should be added to boost::lexical_cast. Whilst I still hold that position for the previous version of the library I believe this is no longer the case for the present version, largely due to the added support for multiple backends. There would be no practical way for lexical_cast to add this, and I believe it to be very useful indeed. -- Did you try to use the library? With what compiler? Did you have any problems? I've tried the library with Clang 3.2 and 3.4, and GCC 4.6 and 4.8 on Mac OS X 10.9.3 and the examples from the documentation using the sstream converter compile and run fine. When I tried the printf_converter something as simple as: #include <boost/convert/api.hpp> #include <boost/convert/converter/printf.hpp> int main(int, char *[]) { return boost::convert<int>::from("23", boost::printf_converter()).value(); } failed to compile. It's missing includes as adding the following to converter/printf.hpp fixes the problem: #include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp> This probably indicates that you're trying to test too much in a single file, and had the includes included via a different boost library. In the previous review I noticed that boost::convert<int>::from('1', cnv).value() spew a rather long error message. This has since been fixed, the error message is now considerably shorter making it easier -- will it ever be easy with C++ -- to figure out what's going on. I must note here that the error message the latest versions of GCC produced is actually easier to figure out than the one Clang produced. -- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something between a quick reading and an in-depth study, now probably leaning towards the latter. -- Are you knowledgeable about the problem domain? As the author of boost::coerce, which I've admittedly ignored for far too long, I'm familiar with the conversion domain. Consequently I've seen the pitfalls and endured the hardships in designing and implementing such a library, my utmost respect for having it reviewed not once, but twice! And finally: -- Do you think the library should be accepted as a Boost library? In my previous review this was a straight no, stating that the functionality should be added to boost::lexical_cast. With the current design supporting multiple backends this no longer holds true as I've stated in the evaluation of the potential usefulness of the library. Again, the library is quite useful, but, I so strongly disagree with the current user-facing interface that I can't straight-out accept it. Once the library is accepted this interface is set in stone and like marriage it's "speak now or forever hold your peace". As such I'm voting YES, CONDITIONALLY on the interface being simplified for the seemingly simple cases as most of my other comments were minor or quite trivial to fix. With that out of the way I'd like to propose the following if you're interested. Let's have a look at whether it may be possible to merge the functionally of boost::convert and boost::coerce, as they seem to have grown towards each other with the possibility to support multiple backends. Two years ago I'd never have proposed this, but I've mellowed a bit since then. You seem to have focussed on backends primarily backed by std::stringstream and friends whereas I have focussed on a backend backed by boost::spirit. These may end up complementing leading to a single library capable of supporting both, being more generic and powerful to the user when done right. Regardless of whether we end up going this way I'd love to have a discussion on the interface, either on the mailing list or offline as this is currently a major stumbling block for me. Jeroen [0] https://github.com/VeXocide/coerce/blob/master/libs/coerce/example/backend.… [1] http://en.cppreference.com/w/cpp/string/basic_string/stol [2] https://github.com/VeXocide/coerce/ [3] http://vexocide.org/coerce/

15 78

Even newer dependency report
by Peter Dimov 12 Jun '14

12 Jun '14

Shows significant progress. http://www.pdimov.com/tmp/report-d6c23cf/module-overview.html http://www.pdimov.com/tmp/report-d6c23cf/module-levels.html

2 3

a new library Global Object Manager submission interest check
by George Georgiev 11 Jun '14

11 Jun '14

Hi, I have code that deals with problems related to initialization of global objects (singletons). 1. Multi-threading - problems occurring in some singleton patterns based on the fact that local for a function or method static variables are not initialized in a thread safe manner 2. Initialization order - there is no multi-platform/multi-compiler standard way to control the global objects initialization order 3. Static linking of global objects code without need - some patterns result in global objects to be linked in the final executable, even if they are provided from static libraries and the code that uses them is not in use 4. Capability for easy replacement of a global implementation object with a mock object I was struggling with shutdown issues in complex c++ application for years in several different projects. With the solution I come up a few years ago I have no issues in any project I have used it. Please let me know if this is something of interest to the boost community. Note that the boost singleton pattern used for path_locale (boost filesystem path) is having the multi-thread issue I mentioned in point 1. This is a small test that demonstrates the problem: https://github.com/ggeorgiev/boost-filesystem-singletons/blob/master/filesy… Thanks, George

3 10

[range] why not adding conversion operator std::pair<FTI.FTI> to boost iterator_range
by Andreas Fabri 11 Jun '14

11 Jun '14

Wouldn't it be a good idea to add a conversion operator to the class iterator_range? This would allow to write functions returning a range, instead of a pair of iterators, but boost::tie would still work with it. Best regards, andreas -- Andreas Fabri, PhD Chief Officer, GeometryFactory Editor, The CGAL Project phone: +33.492.954.912 skype: andreas.fabri

3 4

[BGL]
by Pablo Madoery 11 Jun '14

11 Jun '14

Hello, I Have 2 graphs: graph1 and graph2, and two sets of edge descriptors. One set is associated to edges of graph1 and another set associated to edges of graph2. I don't understand why is it possible to access information about edges of graph2 by using graph1 and the edge descriptors of graph2. I realized of that because of an own mistake when using graphs. What I would like to know is why is that possible to do and if it should be an exception that can handle this situation. I send the code I was using to test this: #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graphviz.hpp> #include <fstream> #include "GraphInfo.h" using namespace std; using namespace boost; typedef adjacency_list<setS, vecS, bidirectionalS, VertexInfo, EdgeInfo> Graph; void printGraph(Graph graph, string file) { ofstream ofs(file.c_str()); dynamic_properties dp; dp.property("node_id", get(vertex_index, graph)); dp.property("label", get(&EdgeInfo::weight, graph)); write_graphviz_dp(ofs, graph, dp); } int main() { Graph graph1; Graph::vertex_descriptor a1 = add_vertex(graph1); Graph::vertex_descriptor b1 = add_vertex(graph1); Graph::vertex_descriptor c1 = add_vertex(graph1); Graph::edge_descriptor e1 = (add_edge(a1, b1, graph1)).first; Graph::edge_descriptor e2 = (add_edge(b1, a1, graph1)).first; graph1[a1].id = 10; graph1[b1].id = 20; graph1[c1].id = 30; graph1[e1].weight = 1; graph1[e2].weight = 2; Graph graph2; Graph::vertex_descriptor a2 = add_vertex(graph2); Graph::vertex_descriptor b2 = add_vertex(graph2); Graph::vertex_descriptor c2 = add_vertex(graph2); Graph::vertex_descriptor d2 = add_vertex(graph2); Graph::edge_descriptor e4 = (add_edge(c2, b2, graph2)).first; Graph::edge_descriptor e5 = (add_edge(b2, c2, graph2)).first; Graph::edge_descriptor e6 = (add_edge(d2, a2, graph2)).first; Graph::edge_descriptor e7 = (add_edge(a2, d2, graph2)).first; graph2[a2].id = 10; graph2[b2].id = 20; graph2[c2].id = 30; graph2[e4].weight = 13; graph2[e5].weight = 14; graph2[e6].weight = 15; graph2[e7].weight = 16; // WHY IS THIS POSSIBLE TO DO // IT IS ASKING FOR AN EDGE OF GRAPH2 BUT USING GRAPH1 ??? double weight = graph1[e7].weight; cout<<"weight: "<<weight<<endl; printGraph(graph1, "graph1.dot"); printGraph(graph2, "graph2.dot"); cout << "end" << endl; return 0; } Thank you very much

1 0

[pimpl] No documentation for pointer semantics
by Edward Diener 10 Jun '14

10 Jun '14

The documentation for "Pimpl with Value Semantics" has: "and was deployed in the previous chapter for the Pimpls with pointer semantics..." but there is no previous chapter about Pimpl with pointer semantics. From that point on the documentation of "Pimpl with Value Semantics makes no sense to me and I do not know what is being explained.

8 24

[Modularization] new Memory module
by Vicente J. Botet Escriba 10 Jun '14

10 Jun '14

|What about creating a Memory module containing| most of the things the standard defines in <memory> except maybe what is already in SmartPptr, e.g. ||* boost/interprocess/allocators/*|| |* boost/intrusive/pointer_traits.hpp Vicente |

5 22

Tick: Trait instrospection library for C++14
by paul Fultz 10 Jun '14

10 Jun '14

Hi, I developed a trait introspection library for C++14 based on Eric Niebler's concept checking, here: https://github.com/pfultz2/Tick So you can build a simple `is_incrementable` trait like this: TICK_TRAIT(is_incrementable) { template<class T> auto requires(T&& x) -> TICK_VALID( x++, ++x ); }; Then use it like this: static_assert(is_incrementable<T>(), "Not incrementable"); Also, you can validate the return of an expressions like this: TICK_TRAIT(is_equality_comparable) { template<class T, class U> auto requires(T&& x, U&& y) -> TICK_VALID( returns<bool>(x == y), returns<bool>(x != y) ); }; You can also match against another trait using placeholder expressions: TICK_TRAIT(is_incrementable) { template<class T> auto requires(T&& x) -> TICK_VALID( return<std::is_integral<_>>(x++), return<std::is_integral<_>>(++x) ); }; Any feedback would be appreciated. Also, I don't knw if there would be any interest in incorporating this into boost. Thanks, Paul

7 13

[config] RTTI detection on Intel C++
by Peter Dimov 10 Jun '14

10 Jun '14

I was going to prepare a simple pull request that basically added #if !defined(__RTTI) && !defined(__INTEL_RTTI__) && !defined(__GXX_RTTI) && !defined(_CPPRTTI) #define BOOST_NO_RTTI #define BOOST_NO_TYPEID #endif to intel.hpp, but then I saw that this file doesn't contain any logic for BOOST_NO_EXCEPTIONS, relying instead on common_edg.hpp to check __EXCEPTIONS. So I wonder whether the preferred approach wouldn't be to check __RTTI in common_edg.hpp instead. Opinions? There's also a slight complication here because I suspect that when Intel is in Microsoft mode, when RTTI is off it will still support typeid, as MSVC does; so just BOOST_NO_RTTI would need to be defined, and not BOOST_NO_TYPEID.

2 2

quickbook equivalent of <simplesect>?
by Peter Dimov 10 Jun '14

10 Jun '14

Does Quickbook support <simplesect> or an equivalent? This is useful for the 'Authors' sections in Core, which don't need to clutter the ToC.

2 9

documentation (ToC) question
by Peter Dimov 10 Jun '14

10 Jun '14

When using Quickbook/BoostBook, how can a section ToC have two levels instead of just one? That is, if we have [library Boost.Core] [section:addressof addressof] [section Header 1] [section Synopsis] [section Example] [section Header 2] [section Synopsis] [section Example] how can the ToC of [section:addressof] show the Synopsis and Example nested within Header 1 and Header 2? I have tried various combinations of generate.section.toc.level, toc.max.depth, toc.section.depth, but nothing seems to produce the result I want.

4 7

[modularization] Recommendations
by Stephen Kelly 10 Jun '14

10 Jun '14

Hello, My last set of recommendations is here: http://thread.gmane.org/gmane.comp.lib.boost.devel/245078/focus=245806 The current graph of strongly connected modules is: http://www.steveire.com/boost/2014_june8_all.dot http://www.steveire.com/boost/2014_june8_all.png The type_traits mpl typeof core form a closed cylce. I consider this a small problem and I recommend deferring efforts to resolve it for now and focusing on the other edges which impact the rest of the graph. It may not be realistic to resolve every cycle or doing so may involve merging modules etc. I recommend deferring that discussion/work until after the major cycle-forming-edges are resolved. Group the above in the graph as a single node for now, removing many cycles: http://www.steveire.com/boost/2014_june8_with_kernel.png http://www.steveire.com/boost/2014_june8_with_kernel.dot Recommendation 1) Move parenthesized_type.hpp from parameter to core This removes the dependency from concept_check on parameter. Recommendation 2) Move implicit_cast.hpp and cast.hpp from conversion to core This also requires moving select_type.hpp from detail to core. This allows removal of the dependencies from iterator and range to conversion. As a side effect, it leaves lexical_cast as the only remaining public header in the conversion library. You can decide what impact that has for the recent 'Extracting lexical_cast from conversion' discussion. This requires removing the include of numeric/conversion/cast.hpp from cast.hpp. The content of that was moved to the numeric library in 2005 and the include was left behind for source compatibility. The result of the above recommendations is: http://www.steveire.com/boost/2014_june8_conversion_rdep.png http://www.steveire.com/boost/2014_june8_conversion_rdep.dot Recommendation 3) Remove use of algorithm from range Range includes boost/algorithm/string/config.hpp for no known purpose. According to git log -S BOOST_STRING_TYPENAME that define was never used in the range library. According to the history of boost/algorithm/string/config.hpp it never really had anything else useful. It might have made sense to include it for the Borland portability with the BOOST_STRING_TYPENAME, but that define was never used in range. Simply remove the use of the boost/algorithm/string/config.hpp header. Use boost/type_traits/detail/yes_no_type.hpp instead of boost/algorithm/string/yes_no_type.hpp in include/boost/range/detail/collection_traits_detail.hpp The resulting strongly connected graph is http://www.steveire.com/boost/2014_june8_range_deps.png http://www.steveire.com/boost/2014_june8_range_deps.dot There are more recommendations which can be made to reduce the strongly connected graph further, but I think the above are enough for now, so let's see if we can get through those first. Thanks, Steve.

6 19

[testing] Dissapearing regression results
by Adam Wulkiewicz 10 Jun '14

10 Jun '14

Hi, I noticed that for the latest runs the tests of Geometry are missing. Surprisingly not all, 2 tests for geometry/index sublib are present. Initially I thought that it may be caused by the recent modularization but I didn't noticed any problems in any of the libraries I checked randomly. Besides, I made some changes in Geometry recently, which AFAIU shouldn't cause any problems, but I guess you may never know. What I changed was: - creation of some files - moving of some files - adding a Jamfile in a directory different than test directories (doc/src/docutils/tools/support_status) - uncommenting tests in file extensions/test/nsphere/Jamfile.v2 So I decided to try running the tests by myself. I tried: 1. Windows + GitBash -> a lot of "can't find xxx file" errors (b2 headers didn't work properly) 2. Windows + GitBash with admin rights -> exactly what can be seen in the tests, bjam.log shows that only 2 tests from Geometry was choosen for testing 3. Windows + cmd with admin rights -> everything is ok (in case you wanted to check it - runner Test2) 4. Linux -> also everything is ok (runner Test) Is it possible that I was lucky and something was fixed yesterday evening (between 2nd and 3rd attempt)? Might my changes cause some problems? E.g. because of some state kept by the runners? In Geometry we have Jamfiles not only in test and xxx/test directories but also in examples, docs and in the main module directory. May this cause some problems? At least for me, on Windows b2 headers now requires admin rights. Otherwise the links just aren't created. Is it because of the replacing hardlinks with symlinks? Another thing is that symlinks aren't properly created for all libraries. AFAIR previously something like this happened after the addition of sublibs file. I don't remember exactly but it was probably caused by the same names of the older tests and newer ones from different directories, so not the same issue? Is there something we could do about it? Regards, Adam

3 9

- Request to join the community maintenance team
by Neil Groves 10 Jun '14

10 Jun '14

Hi! Please may I would like to join all the cool kids in the community maintenance team?! I would like to assist on various maintenance issues and with the modularisation effort. I think this requires broader write access than I have at the moment as a maintainer of Boost.Range. It seems to me that joining the community maintenance team will both allow me to help more with general maintenance and assist with modularisation. If the correct procedure is to make different requests, then please let me know. Regards, Neil Groves

2 1

[pimpl] Boost.Pimpl review canceled
by Glen Fernandes 09 Jun '14

09 Jun '14

Hi everyone, Vladimir has elected to withdraw Boost.Pimpl submission and cancel the formal review. On behalf of Vladimir, thank you for the feedback provided in response to the pre-view announcement mail: it was especially useful to him. Best, Glen

1 0

[Modularization] About adding sub-modules?
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, some libraries can be seen as a set of sub-modules, as it is Math, Numeric or Thread. Could we add these sub-modules ? * Chrono/Stopwatches * Thread/Executors * Detail/WinApi Best, Vicente

4 13

Re: [boost] [Modularization] new Memory module
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

I forget to sent this message to the boost ML. Le 09/06/14 15:18, Vicente J. Botet Escriba a écrit : > Le 09/06/14 12:17, Ion Gaztañaga a écrit : >> El 09/06/2014 10:11, Vicente J. Botet Escriba escribió: >>> Le 04/06/14 13:27, Vicente J. Botet Escriba a écrit : >>>> |What about creating a Memory module containing| most of the things >>>> the standard defines in <memory> except maybe what is already in >>>> SmartPptr, e.g. >>>> >>>> ||* boost/interprocess/allocators/*|| >>>> |* boost/intrusive/pointer_traits.hpp >>>> | >>> Any comments on this new module? Ion? >> >> Thanks for the ping, I'm not closely following modularization threads. >> >> Interprocess allocators are only usable by Interprocess users, I >> don't think they should be outside. > > Sorry, I wanted to say container| > > <boost/container/allocator_traits.hpp>|| > <boost/container/scoped_allocator.hpp>||| > > >> intrusive::pointer_traits is usable from other libraries. Container >> uses it extensively, but Container heavily depends on Intrusive. I >> don't know if other libraries use it. > > Boost.Thread uses allocators for future<T>. >> >> We also have a portable allocator_traits implementation in >> Boost.Container that might be reusable by other boost containers. We >> need to see real use cases to see if this class makes sense in >> Boost.Memory or its place should be Container. > I'm for Memory as it is in the standard. See my use case for future<T> >> >> For Boost 1.56 we'll have new allocators in Boost.Container, and >> those take advantage of Boost.Container internals to offer >> reallocation, burst allocation, etc. They could be usable by other >> Boost containers, but they are still experimental and unless there is >> a strong need for that, I would not move them to a new module now. >> >> pointer_traits offers extensions not found in std::pointer_traits >> (like pointer casting). We need to to carefully think about this >> (Boost.Intrusive needs to make some conversions not covered by >> std::pointer_traits). >> >> In any case, if reusable, I would make a new library (with >> documentation and test cases), not only a new git module. >> > Agreed. >> So my opinion is: Don't move interprocess allocators, let's see if a >> strong need arises for a common pointer_traits/allocator_traits and >> we'll think about solutions. >> > We don't move nothing we can not do either because we are the owners > or because these are libraries managed by the community maintenance team. > > Please, take the time you need about this new module/library that > could contain things similar to the ones found in <memory> except the > smart pointer part. > > Best, > Vicente

2 1

[ublas] Mass test failures on msvc12 and other on all msvc versions
by Adam Wulkiewicz 09 Jun '14

09 Jun '14

Hi, Nearly all tests fails for msvc12 because of the use of constexpr keyword. Could this be fixed? I prepared a pull request nearly a month ago: https://github.com/boostorg/ublas/pull/5 Btw, in those tests failing for all MSVC versions an assertion failure is reported by the STL: map/set iterators incompatible. Assertion failures should be visible in the regression results, shouldn't they? At least in the file test_inplace_solve.cpp (of course with -DUSE_MAPPED_VECTOR_OF_MAPPED_VECTOR) this assertion failure is caused by the matrix_sparse.hpp line 2002: return it_ == it.it_; Which is called by: triangular.hpp line 1328 matrix_expression.hpp line 1598 iterator.hpp line 185 ... test_inplace_solve.cpp line 72 I hope that helps. Do you plan to release the version of uBlas from develop in 1.56? Regards, Adam

4 4

[modularization] proposal and poll
by Julian Gonggrijp 09 Jun '14

09 Jun '14

Dear Boost mailing list members, I would like to revive the topic of Boost inter-library dependencies, suggest two global changes to Boost and ask whether you agree with the course of action I propose. RATIONALE Boost recently transitioned from a monolithic SVN repository to a "modular" Git repository. One of the potential benefits of this new structure is that it may allow users to copy much less of Boost when they need only a small part of it. I believe that two additional, evolutionary changes are needed to truly unlock that benefit. The currently-standard way to use the new Git repository is to recursively clone the super-project and all its submodules, one for each of the >100 libraries. In order to use Boost in a truly modular way, a developer would rather just clone only the libraries she needs (including dependencies). Unfortunately, there is currently no feasible way to do that [see also 1]: - Manually: this is cumbersome and generally hard because there are many (undocumented) interdependencies between Boost libraries. - Automatically: as far as I know Ryppl is the only existing attempt at providing automated dependency handling for Boost, but it is a very ambitious project that attempts to do much more and it is currently neither finished nor being actively developed. I think there could be a less ambitious but faster way to provide automated dependency handling. It would take no more than some static configuration, to list for each library what other Boost libraries it depends on, combined with a simple script that automatically traverses the dependency graph and clones just the necessary submodules. This script may then be hooked into the bootstrap script. I think I could write the dependency handler, and I would be willing to, though I can't currently provide any indication of when I would be able to start. However, even if we had an automated way to handle dependencies, that would not be a sufficient solution to true modularity. As has been discussed before, the interdependencies between Boost libraries are currently so strong, that even using a single header file may likely require the user to copy a substantial portion of Boost [2]. This is especially the case because there are many cyclical dependencies [3, 4]. Stephen Kelly investigated how the interdependencies between Boost libraries could be reduced, especially the cyclical dependencies. He concluded that most cyclical dependencies could be eliminated and that the dependency graph could be simplified substantially overall. He also described concrete ways to achieve this. [3 and onwards] I believe it would still be worthwhile to reduce interdependencies between Boost libraries in the way Stephen proposed, or with a very similar approach. Stephen told me he is willing to re-analyze the dependencies as many times as needed as he did before and to make recommendations. Together with an automated way to handle dependencies, this should enable users to install only a small portion of Boost if that is all they need. It will also make the Boost super- project more flexible overall. PROPOSAL The following (evolutionary) global changes to Boost should be planned and given priority over any other proposals [e.g. 5], in the following order: 1. Reduction of dependencies between Boost libraries. 2. Simple but effective automation of dependency handling. POLL I think it may be easier for the steering committee to justify any decision on this proposal, if they have hard statistics about the amount of support it receives. Therefore, I invite every opinionated person reading this to reply with a vote, either in favour of the proposal or against it. I invite you to do this even if you do not feel the need or find the time to provide arguments for your position. You can later re-vote if you change your mind. I will count the votes, and when there are more than 30 I will start posting the statistics occasionally. Votes are public so everyone can verify my data when necessary. Anyone, including the steering committee, can then use the numbers however they choose. Thanks in advance, -Julian ____________ [1] http://lists.boost.org/Archives/boost/2014/05/213115.php [2] http://lists.boost.org/Archives/boost/2013/10/207379.php [3] http://lists.boost.org/Archives/boost/2013/10/207384.php [4] http://lists.boost.org/Archives/boost/2013/10/207422.php [5] http://lists.boost.org/Archives/boost/2014/05/213229.php

15 49

[1.56.0] Heads up: One week to cutoff for new libraries and breaking changes
by Beman Dawes 09 Jun '14

09 Jun '14

As a practical matter, I'd also like to see the dependency reduction effort wind down for a while so more eyes can shift to finding and fixing master regression test errors. Thanks, --Beman

2 1

detail/interlocked.hpp -> winapi?
by Peter Dimov 09 Jun '14

09 Jun '14

The window for having fun with moving files around is closing quickly, so if detail/interlocked.hpp is going to be moved to winapi, now is the time. It makes atomic depend on detail, which doesn't really matter at the moment, but could become relevant at some later date. C:\Projects\boost-git\boost>%boostdep% boost/detail/interlocked.hpp Inclusion report for <boost/detail/interlocked.hpp> (in module detail): from atomic: <boost/atomic/detail/interlocked.hpp> from interprocess: <boost/interprocess/detail/win32_api.hpp> from log: <boost/log/detail/spin_mutex.hpp> from thread: <boost/thread/win32/basic_timed_mutex.hpp> <boost/thread/win32/interlocked_read.hpp> <boost/thread/win32/once.hpp> <boost/thread/win32/shared_mutex.hpp> <boost/thread/win32/thread_primitives.hpp>

3 9

[type_traits] Proposal: same_xxx
by Adam Wulkiewicz 09 Jun '14

09 Jun '14

Hi, Recently I found some use for a tool adding const to a type if some other type is const. My use case was something like this: typename const_conformant < Range, typename boost::range_value<Range>::type >::type ... I'm guessing that such use cases are quite common, not only for const but also other qualifiers. Do you think that a family of traits adding or removing qualifiers based on the qualifiers of some other type could be a useful addon to the TypeTraits? E.g.: same_const<BaseT, T> same_cv<BaseT, T> same_pointer<BaseT, T> same_reference<BaseT, T> same_rvalue_reference<BaseT, T> same_volatile<BaseT, T> same_extents<BaseT, T> //etc. Regards, Adam

4 5

Let's not forget the release
by John Maddock 09 Jun '14

09 Jun '14

The discussion on reducing dependencies is great, but folks, we do need to produce a release soon, or else it'll be back to bad old days of one release a year (if you're lucky). Just saying... John.

10 15

[atomic]
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, there is a regression on Boost.Atomic on a lot of compilers. See regression test on Boost.Thread http://www.boost.org/development/tests/develop/developer/thread.html synchronized_value__default_ctor_p <https://github.com/boostorg/thread/blob/develop/test/sync/mutual_exclusion/…> Please, could Time or Ardrey take care of this issue? Best, Vicente Test output: jasonr-Ubuntu13.10-gcc - thread - synchronized_value__default_ctor_p / gcc-4.8.1 Rev cfaf6902e696a50a8f8c81510e676aaa547c7706 / Sun, 08 Jun 2014 00:02:00 +0000 Compile [2014-06-08 04:29:08 UTC]: fail "g++-4.8" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -pthread -fPIC -Wextra -Wno-long-long -Wno-variadic-macros -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/hd/boosttest_new/results/boost/bin.v2/libs/thread/test/synchronized_value__default_ctor_p.test/gcc-4.8.1/debug/threading-multi/sync/mutual_exclusion/synchronized_value/default_ctor_pass.o" "../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp" In file included from ../boost/atomic/detail/atomic_template.hpp:25:0, from ../boost/atomic/atomic.hpp:22, from ../boost/atomic.hpp:12, from ../boost/thread/testable_mutex.hpp:14, from ../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp:15: ../boost/atomic/detail/union_cast.hpp: In instantiation of ???union boost::atomics::detail::union_cast(const From&) [with To = boost::thread::id; From = long unsigned int]::<anonymous>???: ../boost/atomic/detail/union_cast.hpp:36:5: required from ???To boost::atomics::detail::union_cast(const From&) [with To = boost::thread::id; From = long unsigned int]??? ../boost/atomic/detail/atomic_template.hpp:355:92: required from ???boost::atomics::detail::base_atomic<T, void>::value_type boost::atomics::detail::base_atomic<T, void>::load(boost::memory_order) const volatile [with T = boost::thread::id; boost::atomics::detail::base_atomic<T, void>::value_type = boost::thread::id]??? ../boost/atomic/detail/atomic_template.hpp:697:27: required from ???boost::atomics::atomic<T>::operator boost::atomics::atomic<T>::value_type() const volatile [with T = boost::thread::id; boost::atomics::atomic<T>::value_type = boost::thread::id]??? ../boost/thread/testable_mutex.hpp:113:30: required from ???bool boost::testable_mutex<Lockable>::is_locked() const [with Lockable = boost::mutex]??? ../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp:24:7: required from here ../boost/atomic/detail/union_cast.hpp:34:12: error: member ???boost::thread::id boost::atomics::detail::union_cast(const From&) [with To = boost::thread::id; From = long unsigned int]::<anonymous union>::as_to??? with constructor not allowed in union To as_to; ^ ../boost/atomic/detail/union_cast.hpp:34:12: note: unrestricted unions only available with -std=c++11 or -std=gnu++11 ../boost/atomic/detail/union_cast.hpp: In instantiation of ???union boost::atomics::detail::union_cast(const From&) [with To = long unsigned int; From = boost::thread::id]::<anonymous>???: ../boost/atomic/detail/union_cast.hpp:36:5: required from ???To boost::atomics::detail::union_cast(const From&) [with To = long unsigned int; From = boost::thread::id]??? ../boost/atomic/detail/atomic_template.hpp:337:137: required from ???boost::atomics::detail::base_atomic<T, void>::base_atomic(const value_type&) [with T = boost::thread::id; boost::atomics::detail::base_atomic<T, void>::value_type = boost::thread::id]??? ../boost/atomic/detail/atomic_template.hpp:687:101: required from ???boost::atomics::atomic<T>::atomic(boost::atomics::atomic<T>::value_arg_type) [with T = boost::thread::id; boost::atomics::atomic<T>::value_arg_type = const boost::thread::id&]??? ../boost/thread/testable_mutex.hpp:47:40: required from ???boost::testable_mutex<Lockable>::testable_mutex() [with Lockable = boost::mutex]??? ../boost/thread/synchronized_value.hpp:431:14: required from ???boost::synchronized_value<T, Lockable>::synchronized_value() [with T = int; Lockable = boost::testable_mutex<boost::mutex>]??? ../libs/thread/test/sync/mutual_exclusion/synchronized_value/default_ctor_pass.cpp:23:76: required from here ../boost/atomic/detail/union_cast.hpp:35:14: error: member ???boost::thread::id boost::atomics::detail::union_cast(const From&) [with To = long unsigned int; From = boost::thread::id]::<anonymous union>::as_from??? with constructor not allowed in union From as_from; ^

1 0

How to identify sub-libraries/modules of a library?
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, I would like to separate the following sub-libraries/modules chrono/stopwatches and thread/executors. Could someone point me where can I find the things to do to split a library in submodules? How to identify them? How to have separated regression test pages? What the new boostdev tool needs? ... Best, Vicente

4 4

[modularization] Removing iterator->conversion dependency
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, in order to remove the dependency from iterator to conversion I suggest to move |boost/implicit_cast.hpp to MPL. | |Vicente | /conversion/ <http://www.pdimov.com/tmp/report-6d1f271/conversion.html> |<boost/implicit_cast.hpp>| * from |<boost/pending/iterator_tests.hpp>| |//boost/implicit_cast.hpp| |template <typename T> inline T implicit_cast (typename mpl::identity<T>::type x) { return x; } |

6 13

[modularization] removing ConceptCheck ->Parameter dependency
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

I suggest removing the ConceptCheck -> Parameter dependency to move|boost/parameter/aux_/parenthesized_type.hpp| to Boost.Detail. Vicente /parameter/ <http://www.pdimov.com/tmp/report-6d1f271/parameter.html> |<boost/parameter/aux_/parenthesized_type.hpp>| * from |<boost/concept/requires.hpp>|

2 5

Guidelines to implement Boost library evolution policy (was Boost 2.0)
by Beman Dawes 09 Jun '14

09 Jun '14

The Boost Steering Committee set the overall policy for Boost library evolution to C++11, C++14, and beyond at its May 2014 meeting in Aspen. Guidelines to implement that policy are now available at https://svn.boost.org/trac/boost/wiki/BoostEvo The plan is to integrate these guidelines with similar material on the web site in time for the 1.56 release. --The Boost Steering Committee

6 13

[modularization] How to remove the Math -> multuplecission dependency?
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, John, ther is a cycle between multuprecision and Math. how can this dependency be removed? /math ->multiprecision/ <http://www.pdimov.com/tmp/report-6d1f271/multiprecision.html> |<boost/multiprecision/cpp_dec_float.hpp>| * from |<boost/math/constants/generate.hpp>| Vicente

4 8

boost::system::error_code and std::error_code
by Vinícius dos Santos Oliveira 09 Jun '14

09 Jun '14

Is there any plans to add a conversion operator from boost::error_code to std::error_code or alike? I was designing a class that I'd like to be usable pleasantly with boost variant of error_code and C++11 variant of error_code, but my design was getting rather complicated (multiple inheritance, templates with no type deduction, ...) and I give up after I came to the make_error_code function, which would be called by the error_code constructor if is_error_code_enum was specialized (which was) and we cannot overload function based on return type (then would be difficult to make it work with boost::system::error_code and std::error_code). TL;DR: What the plans for migration from boost::system::error_code to std::error_code? -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 2

[modularization] Moving <boost/math/common_factor_ct.hpp> to TypeTraits
by Vicente J. Botet Escriba 09 Jun '14

09 Jun '14

Hi, |moving boost/math/common_factor_ct.hpp to TypeTraits would remove the dependency from Interprocess, Pool and Variant to Math. | /interprocess/ <http://www.pdimov.com/tmp/report-6d1f271/interprocess.html> |<boost/math/common_factor_ct.hpp>| * from |<boost/interprocess/allocators/detail/node_pool.hpp>| /pool/ <http://www.pdimov.com/tmp/report-6d1f271/pool.html> |<boost/math/common_factor_ct.hpp>| * from |<boost/pool/pool.hpp>| /variant/ <http://www.pdimov.com/tmp/report-6d1f271/variant.html> |<boost/math/common_factor_ct.hpp>| || * from |<boost/variant/variant.hpp>| Vicente

4 8

core/swap tests appear in core?
by Peter Dimov 08 Jun '14

08 Jun '14

Does anyone know why the core/swap tests, which are in a separate Jamfile, core/test/swap/Jamfile.v2, and have their own line in status/Jamfile.v2, core/test/swap # test-suite core/swap still appear in http://www.boost.org/development/tests/develop/developer/core.html instead of on their own page, core/swap? When they were in utility they did appear on utility/swap: http://www.boost.org/development/tests/develop/developer/utility-swap.html Or, to be more precise, does anyone know how we can make them appear on their own page. :-)

4 5

QVM library
by Emil Dotchevski 08 Jun '14

08 Jun '14

I've updated the QVM library (which hasn't been reviewed yet), including minor changes plus a workaround for what appears to be a parsing bug in msvc-12: http://www.revergestudios.com/boost-qvm/ -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode P.S. Perhaps STL can confirm, I'm guessing that the MSVC bug was introduced by the added rvalue reference support, which interfered with the heuristics MSVC uses to attempt to successfully parse non-conformant code that doesn't use mandatory "typename". This can be seen for example in q.hpp, which used to contain functions like: template <class A,class B> typename enable_if_c< is_q<A>::value && is_q::value, A &>::type operator-=( A & a, B const & b ) which I had to change to: template <class A,class B> typename enable_if< msvc_parse_bug_workaround::quats<A,B>, A &>::type operator-=( A & a, B const & b ) where namespace msvc_parse_bug_workaround { template <class A,class B> struct quats { static bool const value=is_q<A>::value && is_q::value; }; }

2 1

[modularization] chrono/stopwatches
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

Hi, please, could you create a submodule for chrono/stopwatches, or just remove the directory of the files included on the chrono module, as it has not been really released. If this is not possible, I can remove the directory temporarily. Best, Vicente

1 0

[modularization] mpl -> utility dependency
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

The dependency mpl -> utility |<boost/utility/value_init.hpp>| from |<boost/mpl/for_each.hpp>||| |is there just for this line | // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. value_initialized<arg> x; Do we really need to use this value_initialized class to ensure initialization with current compilers? Vicente

2 1

[graph_parallel] Unpushed changes in develop
by Daniel James 08 Jun '14

08 Jun '14

Hi, The develop branch of the super project was manually updated to use a more recent commit that hadn't been pushed to develop. Unfortunately my script for updating the super project doesn't check for this situation and could reset the library to the older version from develop at an arbitrary point (it doesn't normally because it's incremental, but occasionally a non-incremental run will set everything to the current develop branch). So I pushed the current revision to develop. It's just a merge commit that doesn't actually change any code, so I assume it was an oversight that it wasn't pushed. I hope that's okay. Daniel

1 0

[parameter] Literate test, and other changes.
by Daniel James 08 Jun '14

08 Jun '14

Hi, Looking at parameter's history there are three groups of unmerged changes: - "literate" tests extracted from the documentation (plus some small documentation changes) - Stephen Kelly's changes removing workarounds for old compilers - a warning fix - https://github.com/boostorg/parameter/commit/b5e57e0024ae51f5e706eff50e8602… I think they're all okay to merge, although I'm not sure about the literate tests, does anyone know why they weren't merged earlier? They don't show up in the test results, although maybe they're not meant to. Daniel

1 1

Newer dependency report
by Peter Dimov 08 Jun '14

08 Jun '14

http://www.pdimov.com/tmp/report-b932921/module-overview.html http://www.pdimov.com/tmp/report-b932921/module-levels.html

1 0

[Fusion] Heterogeneous comparison rationale?
by Louis Dionne 08 Jun '14

08 Jun '14

Dear list, Is there a reason why Fusion does not support comparing objects of different types? For example, the following will trigger a compilation error inside the library because there is no operator==(int, X): struct X { }; assert(make_vector(1, 2) != make_vector(1, X{})); In the context of programming with heterogeneous types, one could reasonably argue that the above should compile and pass the assertion. Of course, then the library can't use operator== to compare objects internally, but that's an implementation detail. So I'm really looking for a rationale for that design decision and/or comments from people about which way they think it should be and why. Regards, Louis Dionne

1 0

clang failing core/detail_iterator_test?
by Peter Dimov 08 Jun '14

08 Jun '14

Does anyone have any idea why Clang doesn't like detail_iterator_test? As an example, http://www.boost.org/development/tests/develop/developer/output/BP%20x86_64… ../libs/core/test/detail_iterator_test.cpp:79:76: error: no member named 'iterator_category' in 'boost::detail::iterator_traits<iterator<C, T, D, P, R> >' BOOST_TEST_TRAIT_TRUE((is_same<boost::detail::iterator_traits<It>::iterator_category,C>)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^ I'm having endless trouble trying to get a version of Clang up and running here (on Windows), as is customary. This: ../libs/core/test/detail_iterator_test.cpp:136:17: error: default initialization of an object of const type 'const T [5]' T const x[ N ]; ^ I know what is about, and I've fixed that already.

4 7

[config][compatibility] limits.hpp documentation
by Daniel James 08 Jun '14

08 Jun '14

I just created a pull request to update the limits.hpp documentation in compatibility. If no one objects I'll merge it soon. But maybe it should be in config since the header is there now.

1 1

Tick: Trait instrospection and concepts library now for C++11
by paul Fultz 08 Jun '14

08 Jun '14

Hi, I've just update the Tick library to support C++11 compilers including support for gcc 4.6: https://github.com/pfultz2/Tick To support gcc 4.6 an additional `TICK_RETURNS` macro was added. So while this can be written for gcc 4.7 or later: TICK_TRAIT(is_incrementable) { template<class T> auto requires_(T&& x) -> TICK_VALID( returns<int>(x++) ); }; This can be written in order to support gcc 4.6: TICK_TRAIT(is_incrementable) { template<class T> auto requires_(T&& x) -> TICK_VALID( TICK_RETURNS(x++, int) ); }; Of course, the macro is optional and only needed to support older compilers. Any other feedback would be appreciated. Thanks, Paul

3 4

[modularization] First goal clarification: have a DAG dependency graph?
by Vicente J. Botet Escriba 08 Jun '14

08 Jun '14

Hi, I would like what is the first goal of the modularization changes we are doing. IMO, the first one is to have modules that don't have dependency cycles, that is they form a DAG. Reducing the dependencies could be done later on, once we don't have cycles. The next conflicting cycle is Level 3 1/2 mpl - config core predef preprocessor static_assert type_traits utility type_traits - config core mpl preprocessor static_assert typeof utility typeof - config core mpl preprocessor type_traits utility - config core mpl preprocessor static_assert throw_exception type_traits If declval moves from utility to type_traits we break the type_traits->utility dependency. Could we extract *temporally* common_type to a specific module? These break the type_traits -> typeof dependency and the type_traits I say temporary because once all the changes are done to avoid the cycles, we can start looking for better ways to organize the modules preserving always the DAG structure. If we admit these changes we have to resolve this cycle type_traits<=>mpl. We need surely to add every thing that allows to define a trait to either to TypeTraits or to Core without using MPL of course. However in order to see clearer on the dependencies that must be broken to avoid this cycle, could these new file-to-module associations be applied? Best, Vicente

1 0

(no subject)
by Leif Reichert 08 Jun '14

08 Jun '14

1 0

Re: [boost] [pimpl] No documentation for pointer semant
by Dave Gomboc 07 Jun '14

07 Jun '14

[Paul A Bristow]: > I unhappy with a review rigid policy that nothing can be changed during a > review. It isn't always helpful. > > We never accept anything without requiring some changes? > > Can we instead now use git's easy branches to specify a fixed 'master' > branch, but allow the author to update a 'develop' branch as the review > develops? [Edward Diener]: > I believe that changes can be made to a reviewed library during a review > as long as the 'master' branch does not change. After all we want all > reviewers to be looking at the same 'master' branch as the code to be > reviewed. But if the developer wants to make changes to other branches > during the review I think this should be allowed. [Dave Gomboc]: > May I suggest that either the library author or the review manager > ought to, near the commencement of the review, identify a specific > version to be reviewed? This is quite distinct from identifying a > branch name for a conventional branch such as master that is expected > to change frequently even over a two-week period. A specific checkout > is typically identified by a SHA: a branch name such as 'master' is > primarily just an alias to the SHA to which it currently resolves. [Andrey Semashev]: > I think a tag would be a better alternative to a SHA. It's more readable and > GitHub creates a downloadable archive for it so git is not required to review > the library. Sure, using a tag would be great. (I wasn't aware that GitHub had that additional functionality.) Mainly, I have concern that Boost might adopt a procedure whereby committing to master is not permitted during a review. I want to discourage the mindset that changes can't be committed to their logical place (or even at all) just because a review is currently underway, and so tried to show that it is not difficult to avoid such an encumberance. Dave

1 0

[Trac] Adding modules Core, Detail, Sync
by Vicente J. Botet Escriba 07 Jun '14

07 Jun '14

Hi, could we create Component entries on the Trac system for Core -> ?? Detail -> ?? Sync -> Andrey Semashev Vicente

2 1

[core] Breaking bugfix in scoped enums
by Andrey Semashev 07 Jun '14

07 Jun '14

Hi, While creating tests for scoped enums emulation I've fixed a bug which resulted in the enums being convertible to int. This is a potentially breaking change, the code like this will now not compile: BOOST_SCOPED_ENUM_DECLARE_BEGIN(color) { red, green, blue } BOOST_SCOPED_ENUM_DECLARE_END(color) void foo(boost::native_type<color>::type col); color col = color::blue; foo(col); The call to foo() should be done like this: foo(boost::native_value(col)); Previously, the conversion was implicit.

4 7

[pimpl] Some comments
by Andrzej Krzemienski 07 Jun '14

07 Jun '14

Hi Vladimir, My congratulations on the success of Boost.Convert. But I can see you will not have much time to celebrate it, next library waiting in the queue. I wanted to share some of my thoughts on Boost.Pimpl library. This is by no means a review. I am not sure if I will have time to do a decent one. I only skipped through the documentation so my understanding is superficial, but I noticed some things that raise my immediate objection. Boost.Pimpl has been around for a while now, and I remember I was using it at some point in my work, although it didn't have the nice documentation format at that time. [1] The main point in using pimpl idiom (at least my) is to avoid header inclusion, which may grow compilation time too much (at the expense of certain run-time cost). But in order to use Boost.Pimpl I do need to include a header file, which in turn includes more header files. This is arguably less headers that in normal non-pimpl implementation, but it is more than if I used a raw pointer. And this is what I finally did in my work: switched to raw pointers for implementing piml in order to get the build perform faster. (I didn't measure the improvement though.) [2] Boost.Pimpl is good for everyone: people who like value semantics get the value semantic interface, and people who like shated_ptr's get shared_ptr semantics. Call me selfish or biased, but I believe using shared_ptr's should be banned (at least in 90% of the cases where it is currently being used), and the fact that you advertise it first in the docs makes me uneasy. It looks from the docs that 'pointer_semantics' implements something like a flyweight. This is so against value semantics. One of the expectations of types returned by value is that changing the original does no affect the copy: T a = c; T b = c; zap(a); assert(b==c && a!=b); Although the author of class Book knows that it is implemented with pointer_semantics, the users of the class are likely not to know it, and since Book doesn't look like a pointer, they will be expecting value semantics, and will be severely punished. [3] The docs advertize the definition of operator== as a member function. This is against a typical recommendation that it should be a free function in order to avoid asymmetrical behavior in certain cases. Does your library allow the definition of a non-member operator==? If so, I would encourage you to reflect that in the docs. [4] This page: http://yet-another-user.github.io/boost.pimpl/the_boost_pimpl_library/pimpl… says "The advantage of the 'built-in' *Book::null()* [...] is that it makes possible an implementation of strongly exception-safe constructors, the copy constructor" There seems to be something wrong with this statement. How can a strong (commit-or-rollback) guarantee apply to constructors? If an exception is thrown from constructor the object is never created or accessible, so no-one cares about its state (as long as it doesn't leak). Or did you mean the no-throw guarantee? But the latter looks like an anti pattern. What is the value in concealing the exception (and information it carries) and instead produce null objects, which cannot be used? While I find the value_semantics interface useful, I am strongly against even offering the pointer_semantics interface. I am not sure if I have succeeded in explaining why. Regards, &rzej

8 15

[modularization] Extracting lexical_cast from conversion
by Vicente J. Botet Escriba 07 Jun '14

07 Jun '14

Conversion depends on Math and Range due to lexical_cast. /math/ <http://www.pdimov.com/tmp/report-6d1f271/math.html> |<boost/math/special_functions/fpclassify.hpp>| * from |<boost/lexical_cast.hpp>| |<boost/math/special_functions/sign.hpp>| * from |<boost/lexical_cast.hpp>| /range/ <http://www.pdimov.com/tmp/report-6d1f271/range.html> |<boost/range/iterator_range_core.hpp>| * from |<boost/lexical_cast.hpp>| |Extracting LexicalCast allows to break these cycle|s Conversion -> Math -> Conversion -> Range -> Conversion Best, Vicente P.S. This dependencies have been introduced lately while trying to make the implementation more efficient.

5 4

HTTP SERVER 2 Question!
by zyf01234＠gmail.com 07 Jun '14

07 Jun '14

I'm trying to test the HTTP SERVER 2 of the boost.asio samples. some question comes to my mind,so can anyone give me a hand? Q1. The code acceptor_(io_service_pool_.get_io_service()) means get one io_service from the pool , but to this application only one acceptor is created and one io_service is running? Q2 It takes about 25% of the CPU occupancy rate , this is caused by the Q1? zyf01234(a)gmail.com

2 1

Running Tests with Timeouts
by Axel Ismirlian 07 Jun '14

07 Jun '14

Hello everyone, Is there a way to run all of the tests on all of the test suites with timeouts? Occasionally, I need to run all of the tests on all of the test suites, so I leave them overnight only to find out the next morning that one of them hung forever. Sincerely, -Axel

2 1

Review manager for Boost QVM?
by Emil Dotchevski 06 Jun '14

06 Jun '14

Hello, The QVM library has been in the review queue for a some time waiting for a review manager. I've been receiving occasional support requests from random people, and I remember there was at least some initial interest when I proposed the library years ago, but nobody has volunteered to be the review manager yet. This is a library for working with (Q)uaternions and statically-sized (V)ectors and (M)atrices, it's the kind of high level library that is useful to video game programers working with 3D graphics. It's unique (AFAIK) feature is that it uses a type traits system that allows all library functions to operate on 3rd-party types, making it easy to integrate types from different other math libraries into a single type-safe environment. It also has functions that can map vectors as matrices or matrix rows/columns as vectors, or even present mutable transposed view to any matrix, all without creating temporary objects. The documentation and source code can be found here: http://www.revergestudios.com/boost-qvm/ Anyone takers? :) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 8

[modularization] About sub-sub-module path/names..
by Rene Rivera 06 Jun '14

06 Jun '14

This past week I spent time to update my documentation tools to the latest to get the Predef release done. As part of that I created my own mini-Boost that is both minimal to just getting Quickbook compiled and I can control when updating <https://github.com/grafikrobot/boost-doctools/tree/develop>. One frustrating aspect of building that repo was that I made various accidents in adding submodules because of naming. And a key one was the structure for the numeric submodules <https://github.com/boostorg/boost/tree/develop/libs/numeric>. So I have one basic question: Is there a *good* reason why numeric submodules need to have their own subdirectory? It would seem to me much easier to understand if all submodules where flat and on the libs/* dir. The uniformity would also remove various special cases I saw in build and testing code files. For example some special code in Boost/Jamroot <https://github.com/boostorg/boost/blob/develop/Jamroot#L149>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

[core] Detach demangle() from type_info
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi Peter, I can see you already extracted demangle() to boost/core. Great, thanks! However I'd prefer it to be detached from type_info. This tool would be useful with different kinds of symbols, like function and variable names, not just type_info. So it better accept a string as an argument and not type_info. demangled_name() should probably be in core/typeinfo.hpp. And regarding typeinfo.hpp. Aren't we duplicating Boost.TypeIndex here? PS: I was also planning to create pull requests to other libraries to use demangle from Core. These are Exception, Units, TypeIndex and Log, AFAIK. Do you plan to do this? If not, I could.

3 5

[Modularization] unique_ptr (interprocess/smart_ptr) and SmartPtr
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi, what about moving|boost/interprocess/smart_ptr/* to module SmartPtr?| || |||| |||Vicente| ||

3 3

Re: [boost] [pimpl] No documentation for pointer semant
by Dave Gomboc 06 Jun '14

06 Jun '14

[Paul A Bristow]: > I unhappy with a review rigid policy that nothing can be changed during a > review. It isn't always helpful. > > We never accept anything without requiring some changes? > > Can we instead now use git's easy branches to specify a fixed 'master' branch, > but allow the author to update a 'develop' branch as the review develops? [Edward Diener]: > I believe that changes can be made to a reviewed library during a review > as long as the 'master' branch does not change. After all we want all > reviewers to be looking at the same 'master' branch as the code to be > reviewed. But if the developer wants to make changes to other branches > during the review I think this should be allowed. May I suggest that either the library author or the review manager ought to, near the commencement of the review, identify a specific version to be reviewed? This is quite distinct from identifying a branch name for a conventional branch such as master that is expected to change frequently even over a two-week period. A specific checkout is typically identified by a SHA: a branch name such as 'master' is primarily just an alias to the SHA to which it currently resolves. Then again, Boost is relatively new to using git, so perhaps a new branch name can be introduced to refer specifically to the review version. The review manager could, at the commencement of the review, specify the checkout instructions using a specific SHA. For example, for Boost.Pimpl, the manager would provide Source: https://github.com/yet-another-user/boost.pimpl, SHA 59a5c0d or, in command-line-ese, git clone https://github.com/yet-another-user/boost.pimpl git reset --hard 59a5c0d As I mentioned, not everybody may be comfortable working directly with SHAs immediately, so the library author and/or the review manager may wish to introduce a specific label for the purpose of easing identifying the review version. If one of them (or somebody else with write access to the repository) continues from the above two commands with the further git checkout -b boost_review git push origin boost_review then it still becomes possible for the contents of the master branch to change (which, generally speaking, is highly desirable) without disrupting the review process. In this case, the instructions provided by the manager could be: Source: https://github.com/yet-another-user/boost.pimpl, branch boost_review or, in command-line-ese, git clone https://github.com/yet-another-user/boost.pimpl git checkout boost_review which should be more palatable to the large group of people migrating from Subversion. Naturally, in this case it is imperative that boost_review not itself be pushed to further during the review. However, there is no reason the library author from continuing with these commands: git checkout -b boost_review_fixes git push -u origin boost_review_fixes at which point, fixes to items that come up in the review can be pushed onto that branch, and those people who specifically want to take a look at the fixes can easily do so. The above said, the long-term simplicity of specifying a SHA directly instead of a branch at all is not only that one doesn't have to go and make a bunch of new branch names in order to continue development, but even more importantly, one can't push to a SHA to change its contents --because modifying a commit after the fact modifies its SHA also -- so everyone is sure to get the same version of the content being reviewed. Dave

3 2

[optional] Is detail/none_t.hpp needed?
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi, I've noticed there's boost/detail/none_t.hpp header, which basically reflects boost/none_t.hpp. Worse even, it would cause a conflict if both these headers are included. A search didn't reveal any users of this header. Since it's a detail, could this header be removed?

2 5

cstdint.hpp dependency not working?
by John Maddock 06 Jun '14

06 Jun '14

With the recent changes, when building any file that depends on cstdint.hpp I see: link.hardlink ..\..\..\boost\cstdint.hpp Hardlink created for ..\..\..\boost\cstdint.hpp <<===>> ..\include\boost\cstdint.hpp link.hardlink ..\..\..\boost\cstdint.hpp Hardlink created for ..\..\..\boost\cstdint.hpp <<===>> ..\..\integer\include\boost\cstdint.hpp And this happens for every build - even though everything is up to date. Any ideas? Thanks, John.

4 5

A few more critical dependencies
by Peter Dimov 06 Jun '14

06 Jun '14

At present, we have three dependencies that we can easily cut and doing so will be very beneficial: 1. type_traits now depends on utility only because utility: <boost/utility/declval.hpp> from <boost/type_traits/common_type.hpp> from <boost/type_traits/detail/common_type_imp.hpp> from <boost/type_traits/is_copy_constructible.hpp> from <boost/type_traits/is_nothrow_move_assignable.hpp> from <boost/type_traits/is_nothrow_move_constructible.hpp> Since declval.hpp itself depends on type_traits (add_rvalue_reference), it can't go to core and the most logical place for it is type_traits itself. 2. utility depends on iterator because iterator: <boost/iterator.hpp> from <boost/operators.hpp> <boost/iterator/iterator_facade.hpp> from <boost/generator_iterator.hpp> boost/iterator.hpp can be moved to core in all its former glory (and probably replaced by a one-liner, using std::iterator.) generator_iterator.hpp perhaps needs to be moved to iterator. 3. mpl depends on detail because detail: <boost/detail/endian.hpp> from <boost/mpl/string.hpp> <boost/detail/lightweight_test.hpp> from <boost/mpl/aux_/test.hpp> That last one is just because lightweight_test.hpp hasn't been removed from Detail yet; let me know if I should do that. boost/detail/endian.hpp is just a forwarding header that includes <boost/predef/detail/endian_compat.h>. We should move it to Predef. Comments? Objections?

6 20

[core] scoped enum authoring
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi Andrey. In the Boost.Core documentation I see: "Thanks to Andrey Semashev for pointing out that emulation through a namespace could not be used within classes. Helpful comments and suggestions were also made by Kjell Elster, Phil Endecott, Joel Falcou, Mathias Gaunard, Felipe Magno de Almeida, Matt Calabrese, Vicente Botet, and Daniel James." The authors of this file are Beman (for the class based version) and me (for the namespace based). As the documentation has been mainly extracted from the file I would appreciate if both Beman and I are added as authors. BTW, there is no deprecation for the Beman version, there are just different advantages and liabilities. I suspect that the same is applied to the other component of the Boost.Core module Thanks for working on this. Vicente

5 6

[admin][thread] Request for write access fro Niall
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Hi, I would like to give write access to Niall Douglas for Boost.Thread. He has some new features to add and also he could help me to fix some obscure bugs and to maintain the windows port. Can some of the administrators add him as member of the Boost.Thread maintainers team? Thanks, Vicente

2 1

[Config] Announce: New Build time configuration feature
by John Maddock 06 Jun '14

06 Jun '14

In develop only is a new feature to make configuring targets at build time easier, from the docs: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There are times when you want to control whether a build target gets built or not, based on what features the compiler supports. For example, suppose you have a test file "test_constexpr_128.cpp" which requires three key features in order to build: * The constexpr keyword as detected by BOOST_NO_CXX11_CONSTEXPR. * User defined literals, as detected by BOOST_NO_CXX11_USER_DEFINED_LITERALS. * The __int128 data type, as detected by BOOST_HAS_INT128. Clearly we know that if these features are not supported by the compiler, then there's simply no point in even trying to build the test program. The main advantages being: * Faster compile times - build configuration uses lightweight tests the results of which are also cached. * Less noise in build output - there's no reason to be faced with pages of template instantiation backtrace if we know the file can never compile anyway. * Less noise in the online test results - the test will show up as blank, rather than as a fail in the online test matrix. * A better experience for end users building all of Boost, if those libraries which can not be built for the current target compiler are simply skipped, rather than generating pages of error output. Returning to our example, the test case is probably executed in it's Jamfile via the "run" rule: run test_constexpr_128.cpp ; We now need to make this target conditional on the necessary features. We can do that by first importing the necessary rule at the start of the Jamfile: import path-to-config-lib/checks/config : requires ; Assuming that the test case is in the usual directory: libs/yourlib/test then the import rule will actually be: import ../../config/checks/config : requires ; Then add a "requires" rule invocation to the requirements section of the target: run test_constexpr_128.cpp : : : #requirements: [ requires cxx11_constexpr cxx11_user_defined_literals int128 ] ; Notice that multiple arguments can be added to the requires rule, and that these are always the same as the Boost.Config macro name, but in lower case and with the boost_no_ or boost_has_ prefix removed. When building the above example, you will see at the start of the build process the results of the configuration, for example GCC in C++11 mode gives: - Boost.Config Feature Check: int128 : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_user_defined_literals : yes That's all there is to this handy feature, should at any time you be unsure of the feature-test names you can pass to the "requires" rule, then search for the Boost.Config macro of interest in libs/config/checks/Jamfiles.v2, and the name of the feature check will follow it. And finally, this feature is built around the Boost.Build built in rule check-target-builds which can be used to perform more generalized build-time feature testing. The checks in this library are provided as a convenient shorthand without the need for you to write the test cases yourself. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Let me know what you think, and enjoy :-) John.

4 6

[Modularization] Breaking dependecy Range -> Algorithm
by Vicente J. Botet Escriba 06 Jun '14

06 Jun '14

Range depends on Algorithm due to these files /algorithm/ <http://www.pdimov.com/tmp/report-6d1f271/algorithm.html> |<boost/algorithm/string/config.hpp>| * from |<boost/range/detail/collection_traits.hpp>| * from |<boost/range/detail/collection_traits_detail.hpp>| |<boost/algorithm/string/yes_no_type.hpp>| * from |<boost/range/detail/collection_traits_detail.hpp>| * | boost/algorithm/string/yes_no_type.hpp could be moved to TypeTraits|| boost/algorithm/string/config.hpp| could be moved to Config Best, Vicente

1 0

GitHub is slow
by Andrey Semashev 05 Jun '14

05 Jun '14

For the couple past days I'm seeing problems working with GitHub. I can't complete the full update of Boost repository multiple times in a row: ... Fetching submodule libs/regex ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/scope_exit Fetching submodule libs/serialization ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/signals Fetching submodule libs/signals2 Fetching submodule libs/smart_ptr Fetching submodule libs/spirit Fetching submodule libs/statechart Fetching submodule libs/static_assert Fetching submodule libs/sync Fetching submodule libs/system Fetching submodule libs/test Fetching submodule libs/thread Fetching submodule libs/throw_exception Fetching submodule libs/timer ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/tokenizer Fetching submodule libs/tr1 Fetching submodule libs/tti ssh: connect to host github.com port 22: Connection timed out fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Fetching submodule libs/tuple ... Don't mind the particular libraries, they are different every time. I'm also seeing occasional timeouts in web interface. I've seen these problems from two different places, so it's not my local connection. Is anyone seeing this too?

1 0

Boost.Pimpl upcoming formal review (June 15 - June 24)
by Glen Fernandes 05 Jun '14

05 Jun '14

The formal review period of Boost.Pimpl by Vladimir Batov is scheduled to begin later this month, on June 15th, and will conclude on June 24th, and we welcome your participation. Vladimir's library provides a mechanism for implementing this popular, and still very relevant, idiom. To borrow his words from the documentation: [quote] In the domain of commercial large-scale software development the following design principles come to the fore: - component-based, modular and API-centered design, - separation of concerns, - implementation hiding, - minimization of compilation and component dependencies, - consistent and recognizable deployment and implementation patterns, multi-platform support. The Pimpl idiom can help great deal achieving those goals. It is a simple yet robust programming technique to minimize coupling via the separation of public interface and private implementation and then implementation hiding. [/quote] Please feel encouraged to browse the source code, documentation, and tests, before the review commences. Any feedback you have prior to the review period is also very appreciated. Source: https://github.com/yet-another-user/boost.pimpl/ Documentation: http://yet-another-user.github.io/boost.pimpl/ Download: https://github.com/yet-another-user/boost.pimpl/archive/master.zip If you would like to submit a review earlier, please provide your thoughts on the following topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? As well as information on the following questions: - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Best, Glen

1 0

[quickbook] Thank you Daniel James
by Rene Rivera 05 Jun '14

05 Jun '14

After being very surprised that I could build Predef documentation without errors by onyl updating to the latest develop version of Quickbook I had to thank Daniel James. Thank Daniel for the continued work on Quickbook. It's made my life much, much, easier! -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

8 12

Moving utility/declval.hpp to type_traits
by Peter Dimov 05 Jun '14

05 Jun '14

I was going to move utility/declval.hpp to type_traits, but type_traits has many unmerged changes. Since the contents of declval.hpp are currently the same in master and develop, replaying its history on top of type_traits:master and type_traits:develop should not affect any later merges, but still, I always prefer to do this when master and develop are identical, so thought I'd ask first. John?

2 2

[config] intel-linux with -fno-rtti doesn't set BOOST_NO_RTTI...
by Peter Dimov 05 Jun '14

05 Jun '14

... and BOOST_NO_TYPEID. I can see in the config_info output that __RTTI (without the option) is 1, so maybe the check belongs in common_edg.hpp.

1 0

[core] Move underlying_type to type_traits?
by Andrey Semashev 04 Jun '14

04 Jun '14

While documenting and cleaning up scoped_enum.hpp I factored out the underlying_type trait to a separate header. Mostly, because I didn't want to #include <type_traits> in scoped_enum.hpp. boost::underlying_type should be equivalent to std::underlying_type, except that it also supports emulated scoped enums. Perhaps boost/core/underlying_type.hpp should be moved to Boost.TypeTraits?

4 4

Looking for git help for Boost releases
by Marshall Clow 04 Jun '14

04 Jun '14

I’m trying to figure out tooling for making boost releases. One of the missing pieces that we had in SVN was “svn export”, which let you check out a particular branch/revision to a local folder, w/o any of the SVN infrastructure (such as .svn folders). It also let you set the line endings of the files, so I could make a release with Windows line endings on a non-windows computer. The command that I used was: svn export --non-interactive --native-eol XXX -r YYY, https://svn.boost.org/svn/boost/branches/release ZZZ where: XXX was line ending that I wanted (either CRLF for windows or LF for unix) YYY was the revision that I was interested in (usually HEAD) ZZZ was the destination for the export How can I do something like this for git? I’ve looked at “git archive”, and that’s something like what I want, but it doesn’t handle sub-projects. There are a few scripts around that claim to do “git archive over sub-projects”, but I haven’t found one that works with our set up, and none of them let you modify the line endings for (some of) the files as part of the process. Any ideas? Suggestions? Pointers? Thanks in advance. — Marshall

5 10

[Predef] Splitting a version number into components
by Arindam Mukherjee 04 Jun '14

04 Jun '14

Given some vendor version number, is there any macro in Predef to split it into major, minor and patch components? I noticed the macros BOOST_PREDEF_MAKE_* macros. What do these macros help achieve which BOOST_VERSION cannot? Thanks, Arindam

2 3

[atom]
by Christian Henning 04 Jun '14

04 Jun '14

There two compiler errors ( both x86 and x64 ) when building the current master. c:\boost\boost/atomic/detail/ops_msvc_x86.hpp(860) : error C2065: 'order' : undeclared identifier c:\boost\boost/asio/detail/impl/socket_ops.ipp(534) : error C2065: 'SO_UPDATE_CONNECT_CONTEXT' : undeclared identifier I'm using Visual Studio 2013 on Window. The complete output ( x86 release ) is here: http://pastebin.com/raw.php?i=KgnJgWGQ Regards, Christian

2 2

[Modularization] Levels classification
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, could we add a page listing the modules by levels following this rule * A module is in Level 0 if it doesn't depends on other modules * A module is in Level 1 if it depends only on modules at level 0 * A module is in Level N+1 if it depends only on modules at level N or lower levels We have now the following modules that satisfy the rule Moduler levels Level 0 : Config Predef Preprocessor Level 1 : Assert Static Assert Level 2 : Core Level 3 : Utility (After moving string_ref out (???), moving iterator to Core and generator_iterator to Iterator Peter, could you update the Dependency report? Could your report assign a level following this rule and show the modules with an assigned level? Best, Vicente

2 3

[multiprecision] General/design query about which conversions should be implicit/explicit
by John Maddock 04 Jun '14

04 Jun '14

Folks, I have an open bug report https://svn.boost.org/trac/boost/ticket/10082 that requests that conversions from floating point to rational multiprecision-types be made implicit (currently they're explicit). Now on the one hand the bug report is correct: these are non-lossy conversions, so there's no harm in them being implicit. However, it still sort of feels wrong to me, the only arguments against I can come up with are: 1) An implicit conversion lets you assign values such as 0.1 to a rational (which actually leads to 3602879701896397/36028797018963968 not 1/10), where as making the conversion explicit at least forces you to use a cast (or an explicit construction). 2) Floating point values can result in arbitrarily large integer parts to the rational, effectively running the machine out of memory. Arguably the converting constructor should guard against that, though frankly exactly how is less clear :-( Does anyone else have any strong views or insights into this? Thanks in advance, John.

8 8

[GSoC][MPL11] Post C++Now update
by Louis Dionne 04 Jun '14

04 Jun '14

Dear Boost, A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11. The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far. Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress. Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is. Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test. Roadmap ------- Finish exploring the design space. If it turns out that we can merge the MPL and Fusion, then I'll be working on that for a while. If I find that this is not possible or not a good idea, I'll go back to my initial GSoC planning. In both cases, I hope to have a library in the incubator by the end of the summer. Also, this new roadmap is approved by my mentor. Feel free to reply with questions and/or comments. Regards, Louis [1]: http://ldionne.com/mpl11-cppnow-2014 [2]: http://github.com/ldionne/hana

15 34

[master] Building boost 1.56 - only 4 libs are built
by Christian Henning 04 Jun '14

04 Jun '14

When I execute the following command usually all libs are built: bjam -j8 --toolset=msvc --without-mpi variant=debug link=static runtime-link=shared define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE define=BOOST_REGEX_MATCH_EXTRA stage > log_x86_debug.txt But on the current master only three libs are built or copied into my stage folder. libboost_container-vc120-mt-gd-1_56.lib libboost_context-vc120-mt-gd-1_56.lib libboost_exception-vc120-mt-gd-1_56.lib libboost_prg_exec_monitor-vc120-mt-gd-1_56.lib Is my command incorrect? I have been using it for many years. Regards, Christian

4 5

mpl/test/set_c.cpp mystery
by Peter Dimov 04 Jun '14

04 Jun '14

mpl/test/set_c.cpp has been failing for all my toolsets (in both master and develop) with the same error, In file included from ..\..\../boost/mpl/set/aux_/begin_end_impl.hpp:19:0, from ..\..\../boost/mpl/set/set0.hpp:29, from ..\..\../boost/mpl/set/set0_c.hpp:18, from ..\..\../boost/mpl/set/set10_c.hpp:19, from ..\..\../boost/mpl/set/set20_c.hpp:19, from ..\..\../boost/mpl/set_c.hpp:36, from set_c.cpp:14: ..\..\../boost/mpl/set/aux_/iterator.hpp:57:1: error: no type named `base` in `struct boost::mpl::set0_c<bool>` The regression report is all green though, so it was a bit of a mystery. Turned out that I needed to run "b2 headers". So there is an MPL header that b2 misses, although I don't have time at the moment to identify which one. But I decided to report the experience anyway, in case someone runs into the same problem. :-)

1 0

[quickbook] Need some help.
by Andrzej Krzemienski 04 Jun '14

04 Jun '14

Hi, Could someone help me with quickbook format? How can I nest the [section] elements so that this nesting is reflected in the table of contents and html files? I have 2 levels of nesting of element [section]: [section A] [section AA] [endsect] [section AB] [endsect] [endsect] When generatin the html docs , sections AA and AB end up in the same html file. How can I change it? (So that they land in two different files) If it is possible, can I control it by section? Regards, &rzej

3 2

status/expected_results.xml must go!
by Beman Dawes 04 Jun '14

04 Jun '14

In a discussion on the Steering Committee mailing list, Robert Ramey wrote: > I'm still having a problem with a newer library which only supports a more recent version > of C++ such as C++11. Our testing system doesn't permit me to say "don't test this compilers > which don't support C++11". With our current system, anyone who looks at test results will > get failures for compilers which don't support the version his library requires. This is incorrect, > and misleading to potential users of the library, and discourages authors from submitting > libraries which depend on modern C++ features. Also, it wastes a lot of testing time generating > this bogus information. I would ask that the powers that be try to convince the maintainers of > the boost testing setup to address this. The current way we markup expected failures is via boost-root/status/expected_results.xml. That creates two problems: * It is a maintenance nightmare as more and more libraries are added to Boost. This is library-specific information and so should be part of each module, not the super-project. * As Robert points out, we shouldn't even be running tests that are bound to fail anyhow. It would seem that each library needs to be able to tell bjam/b2 to skip certain tests, or even all tests, under certain conditions. As Marshall Clow has been pointing out, we desperately need someone to take over the regression test reporting maintenance, and redesign it to meet our current needs. --Beman

2 2

Unmerged changes in MPL
by Peter Dimov 04 Jun '14

04 Jun '14

The following commits are only in mpl:develop but not in mpl:master: C:\Projects\boost-git\boost\libs\mpl>git log master..develop commit f976861e13f0bb37dd6380c02ccc0d42140daebe Author: Paul <pfultz2(a)yahoo.com> Date: Fri May 16 02:38:50 2014 -0400 Add test for constexpr conversion operator commit ed58434c88ac03816fa0d232c679d551987b42a9 Author: Paul <pfultz2(a)yahoo.com> Date: Sun Dec 29 05:46:32 2013 -0500 Add constexpr to conversion operator for bool integral constants commit 1f482c4fa1d8fc66dc34776b04414f660cc66e76 Author: Paul <pfultz2(a)yahoo.com> Date: Sat Dec 28 23:29:09 2013 -0500 Add constexpr to conversion operator for integral constants What needs to be done with them? Release or revert?

3 2

[predef] Version 1.1 (Boost 1.56)
by Rene Rivera 04 Jun '14

04 Jun '14

FYI.. I've merged over the develop 1.1 version of Predef to master for general use. This should resolve the request from Beman to get this done ASAP :-) Changes for this release include: * Addition of `BOOST_PLAT_*` platform definitions for MinGW and Windows platform variants. * Detection of ARM architecture for Windows compilers to target mobile devices of WIndows 8. * Improved ARM detection for 64 bit ARM. * Added detection of iOS an an operating system. * Improved detection of endianess on some platforms. * Addition of exclusive plus emulated definitions for platform and compiler detection. The big change for this version is the restructuring of the definitions to avoid duplicate definitions in one category. That is, only one `BOOST_OS_*`, `BOOST_COMP_*`, and `BOOST_PLAT_*` variant will be detected (except for sub-categories). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Proposal: Boost.Core
by Peter Dimov 04 Jun '14

04 Jun '14

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities. The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert). Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful". Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers. The following utilities are immediate candidates for migration into the new module: - addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp In addition, the following can be duplicated inside to reduce dependencies: - mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv and so on.

10 51

[Modularization] Moving boost/detail/scoped_enum_emulation.hpp out of Detail
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, |<boost/detail/scoped_enum_emulation.hpp> is a workaround for non C++11|. What about moving it to Config or Core? Vicente

2 3

Report on Primary dependencies for
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, Thanks Peter for providing this dependency report. There is an issue on this report http://www.pdimov.com/tmp/report/thread.html Primary dependencies for thread *unknown* <http://www.pdimov.com/tmp/report/*unknown*.html> |<boost/thread/executors/executor_wrapper.hpp>| * from |<boost/thread/executors/scheduled_executor.hpp>| |<boost/thread/queues/sync_timed_queue.hpp>| * from |<boost/thread/executors/scheduled_executor.hpp>| These files are all inside Boost.Thread. I have just remove two direct dependencies Optional and MPL that were not really necessary. Best, Vicente

2 2

Convert library review manager result
by Edward Diener 03 Jun '14

03 Jun '14

This is my analysis of the 'convert' library review and the result of whether the convert library should be accepted into Boost. Please read the entire analysis to understand my reasoning before reading the result. I would like to thank all of those who took part in the review and made comments. This includes Julian Gonggrip, Rob Stewart, Andrzej Krzemienski, Matus Chochlik, Jeroen Habraken, Erik Nelson, Hartmut Kaiser, Joel De Guzman, Thijs (M.A.) van den Berg, Roland Bock, Gavin Lambert, feverzsj, Paul Bristow, and alex. If I have missed anybody I do apologize. All comments were taken into account and all comments were intelligent and to the point. Naturally I would also like to than Vladimir Batov for patiently answering all comments and explaining and defending his library and his design decisions. For the most part I am going to focus on general issues rather than on the individuals who made them. Documentation issues: The documentation was too focused on explaining the library as it differed from lexical_cast. Vladimir Batov explained why this is so but I also agree that the documentation can be better by simply focusing on what the library provides in terms of functionality. Comments also mentioned that the current converters are not documented as well as the could be, and some commenters reflected that knowledge of how a particular converter works, including possible failures using that converter, is also needed despite the common library interface. The documentation did not provide enough information about the use of locales in the library. The reference section was very limited with not enough explanation. A reference built from doxygen comments in the source files would be better. A better explanation or example in the documentation for writing one's own converter was suggested. Although the Performance section in the documentation was fairly lengthy some commenters wanted to know why some things could not be tested. Others wanted more information about how convert performance compared to other convert-like implementations. In general I think most reviewers found the documentation adequate for understanding how to use the library but lacking in completeness. Vladimir Batov reflected that if the library were accepted into Boost he would then create more complete documentation and the above issues could be addressed. Implementation issues: As in most reviews most commenters did not look very deeply into the actual code but were happy to know how to use the library, and this is understandable for a review. There were a few pertinent comments however and I am just going to enumerate them. All macros should be prefix with BOOST_. My own addition to that is that all macros should be prefixed with BOOST_CONVERT_ to avoid any conflicts with other libraries. There should be a jamfile for running the tests. Also some full-blown examples of using the library in a simple program, along with the appropriate jamfile, would be helpful. Source code should contain spaces, not tabs. This is an easily fixed minor issue. As mentioned before doxygen comments in the public source are the usual Boost way of doing things. The main header file should be convert.hpp instead of api.h. Some includes were missing from the printf converter. Design issues: In the design of the library is where we have the most varying views. The major issue in discussing the design of the library for those who felt it was inadequate were the comments that using the library was too complicated, that the central function for invoking a conversion should be simpler to use. While all suggestions were well-argued I felt that a number of these differences were merely syntactical issues rather than issues that made the functionality easier to use. The main interface for using the library is: convert<output_type>::from(input_value, converter) Vladimir Batov had asserted during the review that this could be simplified further by removing the need for the 'from::' part of the signature which would make the syntax simpler. Some reviewers did not like the name 'convert' and offered substitutions, others wanted the default value, currently specified as '.value_or(default)', to be specified as a direct input parameter, others wanted the converter itself which is an input parameter to be specified via another syntax. All of these are too me syntactical issues and no resolution could possibly please everybody but it is understandable that different reviewers have different syntactical preferences. More to the point were some changes in actual functionality. The three most important involved the return value, type requirements for the output type, and the use of a default converter. Considering each in its turn: 1) The return value is some form of 'optional', with the idea of using boost::optional if it meets all the requirements needed by the 'convert' library. A number of people wanted the actual value returned without having to append .value() to the convert signature to get it. They were also concerned with the performance overhead of having to create an optional value as the immediate return value. It was also suggested that while the current convert syntax might be fine, some alternatives directly returning the value, for those who like maximum simplicity, might be possible. 2) The type requirements for the output type are default constructible and copy constructible. A number of reviewers felt that if a non-const reference were passed to the convert function as an output instance then the type requirements would not have to be met. However the type requirements of some of the underlying converters might be affected by this and the documentation does explain how to work around the default constructible requirement, but I still do understand the reasoning behind this possibility. 3) A number of reviewers wanted a default converter to be used but there was hardly an agreement on what this default converter should be, some favoring lexical_cast, others favoring stringstream, and no doubt others might want something else. Nevertheless providing a default constructor interface, possible with a macro defined a compile time, seems like it might be doable. There was further discussion about the actual callable signature for a plug-in converter. Here there was less contention about the interface, which is currently a callable with a signature of: template<typename TypeOut, typename TypeIn> bool operator()(TypeIn const& value_in, TypeOut& result_out) const; Vladimir Batov did suggest some possible alternatives and there was a discussion with a number of reviewers about alternatives that seem implementable. This also ties into the concern of some reviewers that it should be straightforward to create one's own converters with minimum restrictions on the input and output types, as well as minimum performance overhead. Votes: A number of reviewers made comments but offered no final vote on whether or not the conversion library should be accepted into Boost. Some reviewers offered a Yes vote, but heavily based on changes they want to see. I will attempt to tabulate them here: YES votes: Christopher Kormanyos Paul Bristow Julian Gonggrip ( with some reservations which Vladimir Batove has met or may easily meet ) Andrzej Krzemienski Matus Chochlik YES, conditionally but otherwise NO if conditions are not met, which the current version does not meet] Jeroen Habraken Roland Bock alex NO Rob Stewart Final Decision: Among those who voted YES conditionally but otherwise NO there was a general consensus including Vladimir Batov, the 'convert' library creator, and some of the others that an attempt could be made to satisfy some of the conditions for simplification and/or functionality they desired. My decision, based on the votes as I interpret them, is that the convert library is ACCEPTED into Boost. While a perfect design is impossible I believe that the design of the library is an adequate starting point for a general-purpose conversion framework and that the design could change incrementally enough to satisfy some of the qualms of those who might not find it as initially useful as they have hoped, while still maintaining the central framework which Vladimir Batov has created. Furthermore I believe that others have reflected that a general-purpose conversion library would be very useful if it were flexible enough to support plug-in converters created by programmers, as the 'convert' library does. I realize that what is essentially a 5 to 4 vote in favor of the library is not an overwhelming consensus by any means but I feel that 3 of those 4 NO votes are predicated on wishes for possible changes to the 'convert' library which may yet be met before the library gets officially added to an upcoming Boost release. Since I have accepted the library based on the votes and my interpretation of the issues I would like to encourage those who feel that some alternate designs could be implemented as part of the 'convert' library to work with Vladimir Batov, if he is agreeable, to add those alternatives to the library. Nonetheless it is his library and he would be the final arbiter of any decisions reached. I would like to encourage the view, however, that the current design is what has been voted in by others as the 'convert' library so that any changes made to it as it is added to Boost should be incremental additions which minimally change what others see as an acceptable library.

4 5

boost::python support for python 3.4 enums
by Erik H 03 Jun '14

03 Jun '14

Hi all, Is anyone else interested in boost::python support for Python 3.4 style enums <https://docs.python.org/3/library/enum.html>? Python 3.4 enums have been backported to every Python version you could want, so I use them a lot in my Python code these days. I have many boost::python enum_ instances that have always been problematic due to the complete won't-fix brokenness of boost::python enum nesting (you can nest a boost::python enum in a class's scope, but the type() of the enum is ***WRONG*** because it somehow manages to forget its proper scope, which causes immense and unending pain when something needs to make a new enum_ instance in Python from code that I don't control). So, I am implementing a boost::python::intenum along the lines of boost::python::enum_, but with proper scope nesting provided that I can figure out how to do it. I'll be back with code soon. Best, Erik

1 0

Boost 1.56 timeframe
by Jonathan Jones 03 Jun '14

03 Jun '14

Hi folks, Is there a timeframe for the release of Boost 1.56? The current 1.56 page simply states that it's at an early stage in its release cycle (but it has said this for months). http://www.boost.org/users/history/version_1_56_0.html I'm asking in the context of Visual Studio 2013. Boost 1.55 is known to have issues with VS2013, which I'm hoping the 1.56 release would address. Sincerely, Jonathan Jones

7 10

Pervasive dependency upon mpl::bool_
by Peter Dimov 03 Jun '14

03 Jun '14

We have lots of headers that depend on mpl::bool_ in order to define traits classes as deriving from mpl::true_ or mpl::false_. I don't think that this dependency is necessary even for MPL interoperability. The normal way of template<class T> struct trait { BOOST_STATIC_CONSTANT( bool, value = false ); }; should work just as well. I think. As one example, there's detail/blank.hpp, which starts with #include "boost/mpl/bool.hpp" #include "boost/type_traits/is_empty.hpp" #include "boost/type_traits/is_pod.hpp" #include "boost/type_traits/is_stateless.hpp" It doesn't really need these includes. namespace boost { struct blank { }; // type traits specializations // template <> struct is_pod< blank > : mpl::true_ { }; This can be written as template<class T> struct is_pod; template<> struct is_pod< blank > { BOOST_STATIC_CONSTANT( bool, value = true ); }; which requires no includes. The problem is, though, that all type traits do derive from mpl::true_ or mpl::false_, and I'm not sure if rewriting blank.hpp in the above manner is actually correct. Should type trait specializations always derive from mpl::true_ or mpl::false_? Will I break something if I specialize a type trait to not derive from mpl::bool_? Or is a nested ::value enough? Who knows. :-) But really, if a header, whose entire purpose is to define an empty struct, can't get by without including type traits and mpl, we've lost the dependency game before it's even started.

7 22

[atomic] Help understanding consume order
by Andrey Semashev 03 Jun '14

03 Jun '14

Hi, I'm reviewing (again) Boost.Atomic code and struggling to understand the consume order and in particular what should it mean on architectures other than DEC Alpha. I read the explanation here: http://en.cppreference.com/w/cpp/atomic/memory_order but the point eludes me. Take ARM for example and the explanation in the "Release-Consume ordering" section. The producer thread allocates the string and stores the pointer with a release operation, so that the pointer, the string contents and the 'data' integer are visible to other threads. Now the consumer thread reads the pointer with a consume operation. According to the explanation in the article, on ARM the consume operation need not issue any specific fences to be able to use the pointer and the string body. In that case, the consume operation becomes equivalent to relaxed (plus prohibiting compiler optimizations). But is there a guarantee that the string body will be visible to the consumer? Shouldn't the consume operation be promoted to acquire instead? I guess, that's the ultimate question: how should consume ordering be handled on conventional architectures?

3 6

[iterator][range] Old breaking change in develop.
by Daniel James 02 Jun '14

02 Jun '14

Hi, There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it): https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bd… Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted. Daniel

3 3

github issue
by Christian Henning 02 Jun '14

02 Jun '14

Hi all, I'm cloning boost but something went wrong when trying to get the python submodule. I'm not sure if the problem is related to boost, github, my git setup, or maybe my internet connectivity. Here is a snippet from the console output: ... Cloning into 'libs/proto'... remote: Reusing existing pack: 4233, done. remote: Total 4233 (delta 0), reused 0 (delta 0) Receiving objects: 100% (4233/4233), 1.89 MiB | 893.00 KiB/s, done. Resolving deltas: 100% (2062/2062), done. Checking connectivity... done. Cloning into 'libs/ptr_container'... remote: Reusing existing pack: 2887, done. remote: Total 2887 (delta 0), reused 0 (delta 0)Receiving objects: 98% (2830/28 87), 2.36 MiB | 924.00 KiB/s Receiving objects: 100% (2887/2887), 2.78 MiB | 924.00 KiB/s, done. Resolving deltas: 100% (1839/1839), done. Checking connectivity... done. Cloning into 'libs/python'... ssh: github.com: no address associated with name fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Clone of 'git@github.com:boostorg/python.git' into submodule path 'libs/python' failed I'm using git version 1.9.0.msysgit.0 on Windows 7. Anyone know what's going? Thanks, Christian

2 2

Re: [boost] [modularization] proposal and poll
by Niall Douglas 01 Jun '14

01 Jun '14

I'll top post my reply as Robert's valuable post didn't make it onto the list again. Please do read his reply below, it's worth reading as Robert is one of the lead thinkers on the steering committee about this. Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries. I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are. If their maintainers - or a sponsor - are willing to do: 1. Make their library entirely C++ 11/14 STL based, porting only the absolute minimum of old Boost. 2. C++ Modules ready i.e. restructured and reorganised to properly fit C++ Modules. 3. Contribute any general utility code to the core utilities library, not duplicating any functionality there, and in a form suitable for entering the C++ 17 STL. 4. Meet the raised unit test and CI soak test and sanitiser/valgrind requirements. Then they have a good chance of their library appearing highly ranked in the list of C++ 14 Boost libraries, where that ranking is generated by a set of clang AST analysers. Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again. Right now with the present situation there are few incentives to sacrifice family time. That needs to change for Boost to survive, else the continuing slow decline will continue. Niall On 29 May 2014 at 17:52, Robert Ramey wrote: > > > On Thursday, May 29, 2014 2:17:11 PM UTC-7, Niall Douglas wrote: > > > > On 29 May 2014 at 22:22, Julian Gonggrijp wrote: > > > > If a fork of Boost becomes necessary later this year, > > > LOL - this is not going to be necessary. > > > > The hard part isn't what to do. > > > LOL - not for you! > > > > The hard part is gaining community > > buy in when "their" code gets broken by the necessary changes. I have > > concluded it isn't possible, > > > LOL - you've underestimated the amount of work to convert > everything to C++11 by a factor of .... 1000 ? Basically it's > a whole rewrite of 100 modules. And the gain is ....? > > hence me proposing a fork where such > > "radical" changes won't upset anyone. > > > Your free to do this. And you should if you really believe that > it would benefit anyone or anything. > > > I think it may be easier for the steering committee to justify any > > > decision on this proposal, > > > The steering committee doesn't have anything to decide here. The > "Proposal" is: > > 1. Reduction of dependencies between Boost libraries. > > It's not clear what action is being proposed - but I'm pretty sure > the steering committee won't be doing it. > > 2. Simple but effective automation of dependency handling. > > I'm pretty sure the steering committee won't be doing this either. > If anyone believes that they can implement "simple and > effective" automation of dependency handling - just go ahead > and do it and let us see it. > > > > Decisive and immediate action on this is vital if Boost is to > > survive. I vote yes to both, ASAP. > > > > LOL - There is wide agreement that boost has growing pains and > will have to evolve. But I haven't seen any proposals for > "Decisive and Immediate" which would do anything but make > things worse. > > And since you've got me started - Here is what boost needs go to the next > step. > > a) Make the review process more effective and efficient - we're taking real > practical action to address this now. The jury is still out regarding the > effectiveness of our efforts - but we ARE actually doing something. > > b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11 > and C++14. Our infrastructure doesn't explicitly address this. The > following > needs to change > 1) for each library we need to explicitly state somewhere what > version(s) of C++ the > library is meant to support. > 2) support running of tests and builds for only those platforms. > > I've suggested that we enhance B2 to address this. So far > no one has responded to this suggestion > > Note that this would have he effect of encouraging libraries to evolve > to later versions of C++ with minimal disruption to both library > authors and users. > > c) Decouple Deployment of Boost Libraries from the Certification > of boost libraries. Beman has noted that what he would like to > see is something like CYGWIN whereby one specifies what one > want's and somehow automagically you get that plush what you > need. I realize that this is more or less what is being suggested here. > But no one has presented credible proposal for making it it happen. > > This would also address the issue of "old" libraries. As they > fall into disuse are become superseded by newer ones, the can > still be in boost even though their frequency of deployment drops off. > > The above constitutes a real path forward. This is what Boost > needs for the next 15 years. > > Robert Ramey > -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 4

throw or boost::throw_exception?
by Andrzej Krzemienski 01 Jun '14

01 Jun '14

Hi, I am not sure where, but I am convinced that I have read that it is recommended for Boost libraries that they not use naked throw expressions but instead call boost::throw_exception. Is that true? If so, it enforces a dependency of more than half Boost libraries on Boost.Exception. Am I right? If so, is this the right recommendation in the context of the discussion about reducing dependencies between the libraries? Regards, &rzej

8 22

[next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost
by Vicente J. Botet Escriba 31 May '14

31 May '14

Hi, I've started a new thread in response to Julian Gonggrijp post [modularization] proposal and poll, as I would not answer directly to his questions. I'm sure that almost all of us want a modularized Boost. What does this means? It is up to us to define it: * what the user can request as a delivered package for its own needs? * what the authors must state explicitly? * what must be tested/checked? The main problem is how to achieve it ensuring backward compatibility . I'm persuaded that we need a new Boost repository (or whatever we want to name it) that would include libraries that respect the modularization constraints we could define. My question is who would be interested in starting the next generation of a modularized Boost that starts from a repository of ZERO modularized libraries. The idea is to add to the current Boost libraries new ones that respect the modular rules and adapt the current ones to be defined on top of the modularized ones. At the end we could deprecate the old ones. In order to do that we need of course to add new interfaces (a new namespace mod_boost or whatever is preferred) and so the user would need to move to these interfaces smoothly. Before starting we need to * Define the constraints of a modularized system - no cyclic dependencies, .... * Define the tools that can be used to support the modular system - which build system(s), - which test system(s), - which regression system(s), - which doc system(s), ... * Define the rules - who could be able allowed to do the refactoring? - Should the refactoring be reviewed to ensure a improvement on the quality of Boost? - who maintains what?, ... * Setup the infrastructure ( build system, test system, regression system, doc system, ... ) Only then we could * Start from libraries that don't depend on any other library (with possible refactoring) and adaptation of the refactored libraries from which these modular libraries have been extracted. * Deliver them * Build a second layer of libraries that depend only on first layer * Deliver them * ... Of course, in order to check that the rules and tools are the appropriated ones we will need to experiment with some examples. I recognize that this would mean a lot of work, however I hope that the final result would satisfy better the community expectations and the quality of Boost libraries. Best, Vicente

2 2

[gil] Status of gil:: extension:: io
by William Gallafent 31 May '14

31 May '14

Hi all, I noticed that a major update to gil's io extension was accepted into boost in 2011[1]. It disappeared from its own development repository in 2013[2]. It isn't present in boost 1.55[3]. It is present in boost's subversion trunk[4]. There's currently no mention of it in the release notice for boost 1.56[5]. Am I right to say that its presence in boost trunk means that it /will/ be included in boost 1.56, it just needs to be added to the documentation? If so, then great! Is there anything which needs to be fixed before it's ready to ship? I didn't see anything obvious when I searched this list's archives for “[gil]”. Thanks in particular to Christian, everybody else that worked on the io_new extension, and those that reviewed it! It's very useful to me, and I'm looking forward to its integration into boost so I don't have to add it myself from boost trunk :) [1] http://lists.boost.org/boost-announce/2011/01/0281.php [2] https://code.google.com/p/gil-contributions/source/detail?r=795 [3] http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0/boost/gil/extensio… (this is the “old” io extension) [4] http://svn.boost.org/svn/boost/trunk/boost/gil/extension/io/ (and this is the “new” one) [5] http://www.boost.org/users/history/version_1_56_0.html -- Bill Gallafent.

3 6

[optional] Top level bad_optional_access.hpp
by Andrey Semashev 31 May '14

31 May '14

Hi, I've noticed a new top-level header boost/bad_optional_access.hpp. It wasn't present in 1.55, so it is a recent development. AFAIK, top level headers are discouraged, all library specific headers, except the "include all" header, should be inside the library directory. Am I correct? If so, could this header be moved inside boost/optional?

2 2

Standalone boost::ignore_unused_variable_warning()
by Adam Wulkiewicz 31 May '14

31 May '14

Hi, The ignore_unused_variable_warning() tool is used in many libraries. Its "main" definition (probably the first one) is in concept_check.hpp in the namespace boost but functions of the same name and purpose are also defined in the internals of some libraries (GIL, Interval, Test, uBlas, Unordered), probably to not include the whole concept_check.hpp. So I propose to move this useful tool out of the concept_check.hpp to somewhere else. Since it was already defined in the namespace boost, not boost::detail, the right place would probably be: boost/utility/ignore.hpp or boost/utility/ignore_warning.hpp Furthermore I propose to add a few overloads becasue it's common that the compiler warns about a few variables in the same function, so instead of using N calls: boost::ignore_unused_variable_warning(x) boost::ignore_unused_variable_warning(y) boost::ignore_unused_variable_warning(z) we could use only one: boost::ignore_unused_variable_warning(x, y, z) which would be more convenient to use and read. If you were ok with the change, I'd be glad to hear some tips how to make it in one commit, i.e. to modify two modules at once - modify a file in ConceptCheck and add a file to Utility? And finally I'm considering adding similar tool for unused typedefs because some compilers (GCC4.8) warns about them and there are cases, e.g. when some part of code is shielded with some #ifdef, where they can't be commented out or removed. E.g. something like this would work, though I'm not sure if there is no better way, so I'm open to suggestion. struct empty_type {}; template <typename T1, typename T2 = empty_type, typename T3 = empty_type> struct ignore_unused_typedef_warning {}; int main() { typedef int T1; typedef int T2; ignore_unused_typedef_warning<T1, T2>(); } Regards, Adam

7 19

Re: [boost] [modularization] proposal and poll
by Peter Dimov 30 May '14

30 May '14

It didn't make it through. Please use http://www.pdimov.com/tmp/report.zip to download the report and http://www.pdimov.com/tmp/report/smart_ptr.html (say) to browse it. The version of boostdep I used to generate the report is attached and the generation procedure was as follows: mkdir ..\numeric boostdep.exe --list-modules > ..\modules.txt for /f %i in (..\modules.txt) do boostdep.exe --secondary --html %i > ..\%i.html The links in ..\numeric\*.html are broken because of the subdirectory, but I had no time to fix that. -----Original Message----- From: Peter Dimov Sent: Friday, May 30, 2014 23:37 To: boost(a)lists.boost.org Subject: Re: [boost] [modularization] proposal and poll Clickable HTML report for all modules, attached (if it makes it through).

1 0

Adding detection of [u]intptr_t to Boost.Config (moving it from cstdint.hpp)
by Glen Fernandes 30 May '14

30 May '14

Any objection to me doing this? It would, of course, be non-breaking to anyone currently consuming it from Boost.Integer's cstdint.hpp. Glen

5 12

Is this a MSVC bug?
by Andrzej Krzemienski 30 May '14

30 May '14

Hi, While tracking test failures in Boost.Optional library I discovered that the following program fires an assert in MS VC++ compiler (v. 10.0, 11.0, 12.0): #include <cassert> const int global_i = 0; struct TestingReferenceBinding { void operator=(const int& ii) { assert(&ii == &global_i); } void operator=(int&&) { } }; int main() { TestingReferenceBinding ttt; ttt = global_i; } Do you know if this a bug in VC++, or if that is supposed to be valid? Regards, &rzej

7 10

Anyone is interested in being review manager of ‘Application’?
by Renato Forti 30 May '14

30 May '14

Hi All, The proposed ‘Boost.Application’, needs a Review Manager. Anyone is interested? The Docs: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html The Project: https://github.com/retf/Boost.Application

40 124

[utility][detail] Moving binary_search_test from utility to detail.
by Daniel James 30 May '14

30 May '14

Hi, I've created a couple of pull requests to move this test from utility to detail, as the header it's testing is in detail. I guess it's in utility because there weren't any detail unit tests when it was created. If there are no objections I'll merge them this weekend. https://github.com/boostorg/utility/pull/9 https://github.com/boostorg/detail/pull/2 Daniel

1 0

How do you read this list?
by Gennadiy Rozental 30 May '14

30 May '14

Hi, I am having real problem following boost list nowdays. The second time this year gmane stopped posting RSS feed updates (last time it did not post any updates for like two month) and it was not even updating web interface for like a week recently. Is there any other browser based alternative for reading and posting? Gennadiy

4 4

[smart_ptr][intrusive] boost::unique_ptr<>
by Adam Wulkiewicz 30 May '14

30 May '14

Hi, I remember that there was plans to release an "official" STD-conformant implementation of boost::unique_ptr<>. I found: http://boost.2283326.n4.nabble.com/unique-ptr-for-C-03-td4650231.html http://boost.2283326.n4.nabble.com/C-03-unique-ptr-emulation-td2658449.html Do someone know what's the outcome of this initiative? Regards, Adam

4 6

[test] Looking for co-developer/maintainer
by Gennadiy Rozental 29 May '14

29 May '14

Hi, I think this is somewhat overdue. It's obvious various forces pulling me in different direction won't allow me to continue to do this all by my own. I am still plan to contribute and maintain the library, but I do believe it can be served better if someone can volunteer to share the load with me. There are both maintenance and development tasks in pipe. I have in mind quite a few very interesting features we can extend Boost.Test with (aside from those already requested by users and waiting to be implemented). These include: MT testing support performance testing support Mocking library GUI/DE integration and more Short term though I need help pushing to the release features which are already implemented in trunk and waiting to be released. Major showstopper is absence of proper documentation for these. So one of the first things we'll need to do is to write one. We also need to improve unit testing and finally push this release though some form of boost review. I do not have any specific requirements for the applicant, aside from interest in the library and willingness to work with me. I do not mind several people helping out with documentation, but longer term I'd prefer not very large group of maintainers for the library. If you are interested please shoot me email off list to rogeeff at gmail. Regards, Gennadiy

14 49

[config][predef] Is it OK for boost.config to depend on boost.predef?
by Beman Dawes 29 May '14

29 May '14

There is a config pull request outstanding that includes <boost/predef.h>. If it was almost any library other than config, I'd apply this without a second thought. But Boost config is special in that if it breaks, virtually the whole of boost breaks. So it makes sense to be cautious about dependencies. Has there been any discussion about the relationship between Boost.config and Boost.predef? Even if we accept the patch, is <boost/predef.h> the right header? It just forwards: #include <boost/predef/language.h> #include <boost/predef/architecture.h> #include <boost/predef/compiler.h> #include <boost/predef/library.h> #include <boost/predef/os.h> #include <boost/predef/other.h> #include <boost/predef/platform.h> The rationale for the pull request is a need in other Boost libraries to detect Windows platform variants like BOOST_PLAT_WINDOWS_DESKTOP andBOOST_PLAT_WINDOWS_RUNTIME. Boost.Predef does a nice job of that. But the only header strictly needed is <boost/predef/platform.h>. So the desired effect can be achieved several ways: 1) #include <boost/predef.h> in the include/boost/config/platform/ headers. 2) #include <boost/predef/platform.h> in the include/boost/config/platform/ headers. 3) #include <boost/predef.h> in the files that actually use the desired macros. 4) #include <boost/predef/platform.h> in the files that actually use the desired macros. If I had been writing the code myself, I probably would have selected option (4). What do others think? --Beman

5 11

[utility][optional] boost::equal_pointees -- move it?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, I recently noticed that there is a plan to move everything out of Boost.Utility. Is that right? There is a small feature in there: http://www.boost.org/doc/libs/1_55_0/libs/utility/OptionalPointee.html (header <boost/utility/compare_pointees.hpp>, added along Boost.Optional. Should it be moved out of Utility to Boost.Optional also? If so, any hints on how I should preserve the backwards compatibility for its users? Regards, &rzej

1 0

Re: [boost] [config][predef] Is it OK for boost.config to depend on boost.predef?
by Rene Rivera 29 May '14

29 May '14

On Wed, May 28, 2014 at 12:45 PM, Robert Ramey < robertmacleranramey(a)gmail.com> wrote: > > The whole existence of boost predef was a huge surprise to me. > It was reviewed and accepted ;-) > Looking at the dates it seems its been in boost for a while. I perused > the documentation. I'm still not getting how this doesn't overlap with > config..hpp. I thought that config.hpp was designed to address the issue > of portability between platforms. > Boost Config is indeed designed to address portability between platforms. As a requirement of that design it also has to deal with detecting the different platforms it's trying to define feature/defect macros for. Detecting the platform is not a requirement for Config to work. And you can run the Config configure program to generate a set of portability feature/defect definitions without knowing about the platform. > So I would expect that a facility such as > > #include <boost/predef/platform/windows_desktop.h> > #include <boost/predef/platform/windows_runtime.h> > > would depend upon config.hpp rather than the other way around. > > And since config.hpp is designed to determine the platform automatically, > I'm very surpassed to see predef at all. > "config.hpp" has to partially determine the "platform" by need not by design. > Any additional information you want to submit would be interesting to see. > Predef's design is to *not* detect or define feature/defect macros. All it does is the detection of the platform (compiler, libraries, etc). With enough fine grained platform information one can use it to define know feature/defect macros. Predef defines a much larger superset of the Config platform defs <http://tinyurl.com/o68ovjz> in a consistent (and consistent to check) manner. Or more succinctly: * Predef detects the environment you are compiling in. * Config defines what is or isn't broken with that environment relative to the ideal/standard -conforming environment. HTH -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[config] any macro to detect "Rvalue references for *this"?
by Andrzej Krzemienski 29 May '14

29 May '14

Hi, Is there a macro in Boost.Config that would help me test if a compiler supports a C++11 feature "Rvalue references for *this" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm)? Regards, &rzej

3 11

Adding spirit::is_container to boost::traits
by Rodrigo Madera 28 May '14

28 May '14

Is there any intention of including is_container [1] into boost::traits? I find myself using that particular Spirit header, which could be useful if isolated into traits. Cheers, Madera [1] http://www.boost.org/doc/libs/1_55_0/libs/spirit/doc/html/spirit/advanced/c…

4 9

[interprocess] Is message_queue experiencing problems in 1.55?
by Joseph Van Riper 28 May '14

28 May '14

I'm embarrassed to ask this, but I don't see documentation to help me through a problem like this. I assume I'm doing something wrongly, since I assume someone would have seen something like this earlier. Note that I've boiled this down to the simplest reproducible problem... originally, I tried to simply make use of the message queue using the example code in the documentation, but I can't get past the compile error. I started removing code to find the problem, only to strip ... well ... all of it away. I also tried looking through trac to see if someone already reported this, but I didn't see anything (which doesn't necessarily mean anything, as I may have failed to properly search the thing). Steps to reproduce: 1. On VC++ 2013, create an empty command-line project. 2. At the top of the main .cpp file, add "#include <boost/interprocess/ipc/message_queue.hpp>" 3. Ensure the project can find the boost headers. 4. Compile. Expected result: A completely pointless, but compiled .exe is created. Actual result: Compile error: 1>------ Build started: Project: msgqueue_test, Configuration: Debug Win32 ------ 1> stdafx.cpp 1> msgqueue_test.cpp 1>c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(200): error C2228: left of '.select_on_container_copy_construction' must have class/struct/union 1> type is 'boost::move_detail::add_rvalue_reference::type' 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\intrusive\detail\has_member_function_callable_with.hpp(276) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction_impl<Fun,true,>' being compiled 1> with 1> [ 1> Fun=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\allocator_traits.hpp(262) : see reference to class template instantiation 'boost::container::container_detail::has_member_function_callable_with_select_on_container_copy_construction<const Alloc,>' being compiled 1> with 1> [ 1> Alloc=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\detail\tree.hpp(217) : see reference to class template instantiation 'boost::container::allocator_traits<A>' being compiled 1> with 1> [ 1> A=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\detail\tree.hpp(246) : see reference to class template instantiation 'boost::container::container_detail::intrusive_rbtree_type<A,boost::container::container_detail::tree_value_compare<Key,std::pair<const Key,T>,Compare,boost::container::container_detail::select1st<std::pair<const Key,T>>>>' being compiled 1> with 1> [ 1> A=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> , Key=const boost::interprocess::ipcdetail::sync_id * 1> , T=boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>> 1> , Compare=boost::interprocess::ipcdetail::sync_handles::address_less 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\container\map.hpp(83) : see reference to class template instantiation 'boost::container::container_detail::rbtree<Key,std::pair<const Key,T>,boost::container::container_detail::select1st<std::pair<const Key,T>>,Compare,Allocator>' being compiled 1> with 1> [ 1> Key=const boost::interprocess::ipcdetail::sync_id * 1> , T=boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>> 1> , Compare=boost::interprocess::ipcdetail::sync_handles::address_less 1> , Allocator=std::allocator<std::pair<const boost::interprocess::ipcdetail::sync_id *const ,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<std::pair<const boost::interprocess::ipcdetail::sync_id,void *>>>>> 1> ] 1> c:\users\tvanriper\documents\code\sdks\boost\include\boost-1_55\boost\interprocess\sync\windows\sync_utils.hpp(226) : see reference to class template instantiation 'boost::container::map<const boost::interprocess::ipcdetail::sync_id *,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<T>>,boost::interprocess::ipcdetail::sync_handles::address_less,std::allocator<std::pair<const Key,boost::unordered::iterator_detail::iterator<boost::unordered::detail::ptr_node<T>>>>>' being compiled 1> with 1> [ 1> T=std::pair<const boost::interprocess::ipcdetail::sync_id,void *> 1> , Key=const boost::interprocess::ipcdetail::sync_id * 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

2 2

Is there any interest in a library for actor programming?
by Charousset, Dominik 28 May '14

28 May '14

Hi, is there any interest in a library for actor programming? The library we've developed is a C++11 open source library named "libcppa". It is currently released under LGPL2, but re-releasing the library under the boost license is not an issue. You'll find all important links and ressources either under http://libcppa.org or on the GitHub project page: https://github.com/Neverlord/libcppa, including a user manual as HTML or PDF. We've also submitted a paper to the C++Now conference. What is actor programming? For those of you who aren't yet familiar with the actor model: actors basically represent tasks or services that communicate via message passing. In libcppa, actors are very lightweight (you can spawn literally millions of them) and scheduled cooperatively using a thread pool (although actors are allowed to opt-out of the cooperative scheduling). Some of the main strengths of this programming paradigm are: (1) network transparency, (2) race conditions are avoided by design, (3) a strong failure model that enables developers to build reliable distributed systems, and (4) the actor model addresses both concurrency (multiple actors on one host) and distribution (any number of actors on any number of hosts). Here's the classical hello world example: ---------------------------------------------------------------------------------- #include <string> #include <iostream> #include "cppa/cppa.hpp" using namespace std; using namespace cppa; void mirror() { // wait for messages become ( // invoke this lambda expression if we receive a string on_arg_match >> [](const string& what) { // prints "Hello World!" via aout (thread-safe cout wrapper) aout << what << endl; // replies "!dlroW olleH" reply(string(what.rbegin(), what.rend())); // terminates this actor ('become' otherwise loops forever) self->quit(); } ); } void hello_world(const actor_ptr& buddy) { // send "Hello World!" to our buddy ... sync_send(buddy, "Hello World!").then( // ... and wait for a response on_arg_match >> [](const string& what) { // prints "!dlroW olleH" aout << what << endl; } ); } int main() { // create a new actor that calls 'mirror()' auto mirror_actor = spawn(mirror); // create another actor that calls 'hello_world(mirror_actor)' spawn(hello_world, mirror_actor); // wait until all other actors we have spawned are done await_all_others_done(); // run cleanup code before exiting main shutdown(); } ---------------------------------------------------------------------------------- A message is simply a tuple of values that is pattern matched at the receiver. For example, " on_arg_match >> [](const string& what) {...}" defines a message handler that is called whenever a tuple with one single string element arrives. "on_arg_match" simply defines a pattern that matches the signature of the given lambda. Please have a look at the examples folder on GitHub (https://github.com/Neverlord/libcppa/tree/master/examples) or at the user manual (http://neverlord.github.io/libcppa/manual/) if you want to see more examples. Best regards, Dominik Charousset

17 62

[foreach] Can should_copy_impl return type be simplified?
by Mostafa 28 May '14

28 May '14

I'm studying the implementation of foreach and I had a question about should_copy_impl. For reference, here's the overload that's vexing me: // If the collection is an array or is noncopyable, it must be an lvalue. // If the collection is a lightweight proxy, treat it as an rvalue // BUGBUG what about a noncopyable proxy? template<typename LValue, typename IsProxy> inline BOOST_DEDUCED_TYPENAME boost::enable_if<boost::mpl::or_<LValue, IsProxy>, IsProxy>::type * should_copy_impl(LValue *, IsProxy *, bool *) { return 0; } Why is enable_if needed? Can't the return type just be "IsProxy *"?

2 1

[Math] Rationale Behind Epsilon Values
by Axel Ismirlian 28 May '14

28 May '14

Hello, I am new to this mailing list, so its possible the format of my question may be off by a little. My team has been working on getting boost to run on PPC 64-LE. There are many tests in boost that rely on the machine epsilon value. Why was this value chosen to determine success or failure of a particular test knowing that it is hardware specific? More specifically, the Long Double type is very different on both platforms. However, by forcing the x86 Long Double epsilon value on the PPC machine we were able to get many of the previously failing tests to pass. This change was inspired by the fact that a similar fix was already in the code for Darwin platform, but the value that it returns for the Darwin platform is not the x86 value. Also the LDBL_MANT_DIG on both the Darwin platform and our platform (PPC 64-LE) are the same, and are equal to 106. How was the Long Double value on the Darwin platform determined? For reference, the actual code lies in boost/math/tools/precision.hpp. We were also wondering whether or not this was a valid solution to fixing the problem? Part of us feel this doesn't address the underlaying problem. Sincerely. -Axel

3 3

[convert] An approach that might actually work. :-)
by Vladimir Batov 28 May '14

28 May '14

To move forward in a coordinated way how about we create a working group (say, >= 5 people). Then we'd address convert-related issues in the order of importance. Public API first, converter API then, etc. (Or maybe some other design altogether). We'd focus on one thing at a time. Discuss it and then vote. The solution accepted by the majority wins, we document it and move forward to the next item of importance... without running in circles about the previous issues... unless we realize down the track that our solution is flawed somehow. That won't require any more of the time of the participants than it is now. I am happy to coordinate (whatever that might be), do implementation (to the best of my abilities), etc. Still, if anyone feels strongly about doing that "coordination" thing, step forward, no drama. Such collaborative approach would take subjectivity out and might bring new unexpected ideas, etc. That I think might actually work. Any one willing to sign up? Jeroen, Roland, Rob? What people think? Let me know if you feel like participating, contributing... If there is no appetite for that, it's still OK. -- View this message in context: http://boost.2283326.n4.nabble.com/convert-An-approach-that-might-actually-… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 3

Compiling without Long Double Support
by Axel Ismirlian 28 May '14

28 May '14

Hello, My team and I are working to make boost compatible with PPC 64-LE and we were wondering how to compile boost without long double support, so that in the mean time we can isolate other problems not related to floating point problems. Sincerely, -Axel

2 1