- Boost - lists.boost.org

[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>(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<U>(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