June 2014 - Boost - lists.preview.boost.org

[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