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

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

[build] b2 headers broken?
by Eric Niebler 02 Mar '15

02 Mar '15

I just updated to the latest develop. I ran bootstrap, then nuked my boost directory and reran b2 headers. Worked fine. Then I changed directory to libs/proto/test and ran ../../../b2 mem_ptr to run a test. Here's what I get: f:\modular-boost\libs\proto\test>..\..\..\b2 mem_ptr Performing configuration checks - symlinks supported : no - junctions supported : yes - hardlinks supported : yes ...patience... ...patience... ...found 4951 targets... ...updating 441 targets... common.mkdir ..\..\..\bin.v2\libs common.mkdir ..\..\..\bin.v2\libs\proto common.mkdir ..\..\..\bin.v2\libs\proto\test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0 common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static common.mkdir ..\..\..\bin.v2\libs\proto\test\mem_ptr.test\msvc-12.0\debug\link-static\threading-multi link.rm ..\..\..\boost\mpl common.mkdir ..\..\..\boost\mpl link.hardlink ..\..\..\boost\mpl\print.hpp Hardlink created for ..\..\..\boost\mpl\print.hpp <<===>> ..\..\mpl\include\boost\mpl\print.hpp <snip> link.rm ..\..\..\boost\numeric\conversion link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp The system cannot find the path specified. if exist "..\..\..\boost\numeric\conversion\conversion_traits.hpp" del "..\..\..\boost\numeric\conversion\conversion _traits.hpp" mklink /H "..\..\..\boost\numeric\conversion\conversion_traits.hpp" "..\..\numeric\conversion\include\boost\numeric\ conversion\conversion_traits.hpp" ...failed link.hardlink ..\..\..\boost\numeric\conversion\conversion_traits.hpp... link.hardlink ..\..\..\boost\numeric\conversion\int_float_mixture_enum.hpp The system cannot find the path specified. For some reason, b2 thinks it needs to rerun b2 headers, but it does a crap job of it and dies. What's going on? Eric

4 6

Interactive metaprogramming shells
by Abel Sinkovics 28 Dec '14

28 Dec '14

Hi, I've built interactive shells for preprocessor and template metaprogramming. I've been using them for development and debugging of metaprograms and I think Boost developers could also find them useful. You can type in (metaprogramming) expressions which get evaluated and the result is displayed immediately. For example you can type boost::mpl::push_front<boost::mpl::vector<int, char>, double>::type and you get boost_::mpl::vector<double, int, char> as the result (the boost_ namespace is used because there are some tricks there to make the output more readable). As an example for the preprocessor shell you can type BOOST_PP_REPEAT(3, foo BOOST_PP_TUPLE_EAT(3), ~) and you get foo foo foo as the result. The tools are based on the Boost.Wave library and Clang. You can get them here: Preshell for preprocessor: https://github.com/sabel83/preshell Metashell for template metaprograms: https://github.com/sabel83/metashell You can also try them from your browser here: http://abel.web.elte.hu/shell Feedback is welcome. Regards, Ábel

6 16

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Review request for Compute
by Antony Polukhin 10 Dec '14

10 Dec '14

Hi, Please add the the Compute library to the review schedule. Compute is a GPU/parallel-computing library for C++ based on OpenCL. Author: Kyle Lutz Source code: https://github.com/kylelutz/compute Documentation: http://kylelutz.github.io/compute/ Review Manager: Antony Polukhin Approximate review date: end of November - December 2014 -- Best regards, Antony Polukhin

2 2

[mpl] [build] [testing] Merge pull requests
by Andrey Semashev 08 Dec '14

08 Dec '14

Hi, There were a lot of discussions about MPL recently, and I created a few pull requests to address issues: https://github.com/boostorg/boost/pull/39 Invoke 'headers' target before building testing tools. Note that several testers are currently failing to run because of this problem. Since this affects the testing process, I'd appreciate if someone familiar with it could take a look. https://github.com/boostorg/boost/pull/38 Add MPL.Core tests to the test report. These tests are currently not run by testers. https://github.com/boostorg/mpl/pull/12 Move a misplaced header from MPL to MPL.Core to resolve circular dependency between the two. I believe the first PR is especially critical. Could someone with permissions merge these? Thanks.

13 52

[Range] New I/O functions for ranges
by Indiana 25 Nov '14

25 Nov '14

I'm currently putting together a proposal to the standards committee about a set of range I/O functions, but i think they would make a good addition to Boost as well. They would probably fit in the Range library - i don't think they warrant a library all of their own. The stuff i wrote for the standards proposal is available at http://cpp.indi.frih.net/rangeio/ - it goes into quite a bit of detail about the interface, and links to a sample implementation. But here's the executive summary: There is a single output function - currently called "write_all" - that takes a range and, optionally, a delimiter, like this: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 4>{1, 2, 3, 4}; cout << write_all(r); // prints "1234" cout << "{ " << write_all(r, ", ") << " }"; // prints "{ 1, 2, 3, 4 }" // END CODE /////////////////////////// It takes anything that works with range-for, so it works with range adaptors: // BEGIN CODE ///////////////////////// struct is_even { auto operator()(int x) const -> bool { return x % 2 == 0; } }; cout << write_all(r | reversed | filtered(is_even{})); // prints "42" // END CODE /////////////////////////// Note also that the delimiter doesn't have to be a string (there are some examples in the reference of that). Why not just use std::copy() and stream iterators? Several reasons - the most obvious of which you can see above: this syntax is much cleaner, much less error-prone, well-integrated with the existing stream I/O mechanisms, and it produces properly delimited output (unlike the delimited version of ostream_iterator). But also, stream formatting is properly handled: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 3>{1, 2, 3}; std::cout.width(3); std::cout.fill('0'); // --------------------------- // The old way: using std::begin; using std::end; std::copy(begin(r), end(r), std::ostream_iterator<int>{std::cout, ", "}); // even with Boost.Range, this just reduces to: //boost::copy(r, std::ostream_iterator<int>{std::cout, ", "}); // prints: "001, 2, 3, " // --------------------------- // The new way: std::cout << write_all(r, ", "); // prints "001, 002, 003" // END CODE /////////////////////////// And of course this works as expected in chained expressions: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; cout.width(3); cout.fill('0'); cout << '(' << setw(3) << setfill('0') << write_all(r, ',') << ')'; // prints: "(001,002,003)" // END CODE /////////////////////////// It is also possible to get more information about errors, and react better to them. If there is an error in the formatting or in the stream during an output operation using std::copy() and ostream_iterator, the algorithm will chug merrily along until it's all the way through the range even though it's no longer writing anything. You will have no way to detect where the problem occurred - did it fail after the first element was written, or *before*, or did it fail after the millionth element? If the range is begin lazy-generated, that could be particularly wasteful, or even problematic. By contrast, write_all() stops immediately when there is an error in the output stream. It is even possible get more information about the last range write operation by capturing the temporary object, like this: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; auto p = write_all(r); cout << p; if (!cout) { cerr << "only " << p.count << " elements written\n"; cerr << "next element would have been " << *p.next << '\n'; } // END CODE /////////////////////////// On the input side, there are 7 functions: * overwrite * back_insert * front_insert * insert * back_insert_n * front_insert_n * insert_n Overwrite simply replaces the contents of a range with whatever is read from input: // BEGIN CODE ///////////////////////// auto r = array<int, 100>{}; cin >> overwrite(r); // reads up to 100 ints // END CODE /////////////////////////// The *insert functions map to the *insert_iterators in the standard library, using push_back(), push_front(), or insert(). In each case: in >> ???insert(r[, i]); is basically equivalent to: copy(istream_iterator<value_type_of_r>{in}, // use braces on the next line, or face the most vexing parse istream_iterator<value_type_of_r>{}, ???inserter(r[, i])); The *insert_n functions are for the common case where you know in advance how many elements will be read, at maximum - or for when you want to limit the amount of elements read in a single read operation. This: in >> ???insert_n(r[, i], n); is conceptually equivalent to: copy_n(istream_iterator<value_type_of_r>{in}, n, ???inserter(r[, i])); except it can handle formatting and errors properly. The reference at http://cpp.indi.frih.net/rangeio/ goes into much more detail, of course. Why add it to Boost? Because these operations (reading/writing ranges) are so common they are almost universal, and there is no standard facility that handles them easily or well. They are not *difficult* to implement, but they are far from trivial - for example, you might think write_all() is just a simple range-for loop or for_each(), and it is... up until you add error checking, the delimiter, and formatting awareness. A sample implementation already exists - it can be implemented portably in pure standard C++11. (Can it be implemented in C++03 with? Good question. It might be possible with some Boost help, but it might require dependencies on libraries other than Boost.Range. If this proposal finds approval, that's something i can look into.) Would there be any interest in adding these functions to Boost.Range?

5 13

Changes in Boost.Optional
by Dean Michael Berris 24 Nov '14

24 Nov '14

Suppose I have the following type: struct container { boost::optional<uint16_t> optional() const { return value_; } private: boost::optional<uint16_t> value_; }; struct value_wrapper { value_wrapper(const container& c) : c_(c) {} operator uint16_t () { return 1; } operator boost::optional<uint16_t>() { return c_.optional(); } private: const container& c_; }; And that I have the following function: value_wrapper value(const container& c) { return value_wrapper(c); } The following used to work in MSVC 2010: container c; // leave c.value_ alone. boost::optional<uint16_t> some_value = value(c); assert(!some_value); Now with Boost 1.56, this breaks because the constructor for some_value from a temporary optional is now marked explicit. What is the work-around for the previous behavior to be regained? All the following changes cause the assertion to fail: boost::optional<uint16_t> some_value(value(c)); assert(!some_value); // some_value's constructor will use the uint16_t conversion operator, therefore some_value == 1 boost::optional<uint16_t> some_value = static_cast<boost::optional<uint16_t> >(value(c)); assert(!some_value); // same problem as above, the temporary created will favor the uint16_t conversion operator Help? PS. For better context, see https://github.com/cpp-netlib/cpp-netlib/blob/0.11-devel/boost/network/prot…

8 26

Ticketspam
by Daniel Frey 17 Oct '14

17 Oct '14

One more to remove: <https://svn.boost.org/trac/boost/ticket/10560> Thanks, Daniel

10 18

It's that time again already - Boost 1.57.0 schedule
by Marshall Clow 08 Oct '14

08 Oct '14

It’s that time again. Here’s the schedule for the upcoming 1.57 release. If you’ve got changes that you’ve been putting off making, now’s the time to get busy. * 13-Oct Last day for significant changes * 20-Oct Beta build * 27-Oct Automatic merging turned off, build an RC * 3-Nov Release Boost 1.57.0 Questions? Ask them here. — The Boost release managers. P.S. We’ll be updating the calendar on boost.org/development soon.

5 5

Submodules of Boost libraries
by Mathias Gaunard 07 Oct '14

07 Oct '14

Hi folks, I'd like to ready my library for inclusion into Boost. My library is made of several modules, and I'd like to keep that into Boost. How does Boost handles multiple submodules within a library submodule?

7 11

[modularization] LocalFunction and ScopedExit cycle
by Vicente J. Botet Escriba 06 Oct '14

06 Oct '14

2 3

[static_if] Is there interest in a `static if` emulation library?
by Lorenzo Caminiti 01 Oct '14

01 Oct '14

Hello all, With C++14 generic lambdas, it is possible to implement a sort of `static if` (see also N3613): template< typename T > void assign ( T& x, T const& y ) { x = y; static_if<boost::has_equal_to<T>::value>( std::bind([] ( auto x, auto y ) { assert(x == y); std::cout << "asserted for: " << typeid(T).name() << std::endl; }, x, y) ).else_( [] ( ) { std::cout << "cannot assert for: " << typeid(T).name() << std::endl; } ); } The bind around the generic lambda is a bit verbose... but this code compiles, asserts when called on int, and does not assert when called on x_t (tested on clang 3.4.2): int i = 1; struct x_t { } x; assign(i, i); // asserts assign(x, x); // does not assert I have attached a reference implementation. Thank you. --Lorenzo P.S. I didn't do much background research... sorry if this topic has already been considered and discussed in Boost.

17 43

[move] Build failures in develop
by Andrey Semashev 01 Oct '14

01 Oct '14

Hi, I'm seeing lots of build errors that originate from Boost.Move, such as: In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_function<void ()> > >' : T::type ~~~^~~~ See the full error logs: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… http://www.boost.org/development/tests/develop/developer/output/teeks99-08b… http://www.boost.org/development/tests/develop/developer/output/teeks99-tes… I didn't change Boost.Log for quite some time, so there seems to have been some breaking change. Could this be fixed?

3 7

[thread] Build failures in develop
by Andrey Semashev 01 Oct '14

01 Oct '14

Hi, Boost.Thread currently fails to build on MSVC, which affects other libraries: http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… Could it be fixed?

4 6

[modularization] request for a new modularization status for develop branch
by Vicente J. Botet Escriba 01 Oct '14

01 Oct '14

Hi Peter, could you upload a new modularization status, as in http://www.pdimov.com/tmp/report-d53f656/module-levels.html ? Best, Vicente

4 7

[Modularization][optional][functional] boost::none - what do we want it to be?
by Andrzej Krzemienski 30 Sep '14

30 Sep '14

Hi Everyone, I know it may be premature to to think about removing every cycle in Boost, but while looking at the cycle reports I found that at least one library is using boost::none, for a purpose different than indicating an uninitialized boost::optional. It is in Boost.Functional: https://github.com/boostorg/functional/blob/master/include/boost/functional… It uses none_t as a default type for a template type parameter Allocator. My question is: what do we want boost::none_t to indicate, at least in Boost? 1. A value-semantic alternative to void, that anyone can use? 2. A tag indicating boost::optional<T> without a value? The answer to this question dictates how we should untie the cycle. I know it is too soon to care about small cycles right now, but my question is more about "the principles". Regards, &rzej

2 2

"Easy Build and Install" fails at bootstrap.sh
by Josh Juran 30 Sep '14

30 Sep '14

I'm building Boost from Git since there's no secured download option, only HTTP. josh@alice:~/src/boost$ git log --oneline -n1 43bb782 Update thread from master. josh@alice:~/src/boost$ ./bootstrap.sh ./bootstrap.sh: 1: ./bootstrap.sh: ./tools/build/src/engine/build.sh: not found Building Boost.Build engine with toolset ... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details josh@alice:~/src/boost$ cat bootstrap.log ./bootstrap.sh: 218: cd: can't cd to ./tools/build/src/engine Do I need to run git-submodule? It would be helpful if Getting Started covered this. Josh

4 3

[iostreams]Bugs in dual seekable mode
by Jorge Lodos 29 Sep '14

29 Sep '14

Currently there are no tests for dual seekable streams. New tests (dual_seekable_test.cpp in the ticket) uncover the following bugs: 1. The functions test_seekable_in_chars and test_seekable_in_chunks in test/detail/verification.hpp use seekp in several places where seekg should be used. This has no effect when there is a single head but does not work when the stream is dual seekable. 2. indirect_streambuf::seek_impl does not work for dual seeking. The problem is that both heads are modified for both input and output operations. Since the modification is the same (just resetting the pointers) everything works when there is a single head. This is a duplicate of https://svn.boost.org/trac/boost/ticket/7681. 3. The function shared_buffer() does not consider dual_seekable stream buffers as shared. 4. The function init_put_area() does not consider the existing input position. This is a duplicate of https://svn.boost.org/trac/boost/ticket/8572. With the attached (in the ticket) versions of verification.hpp and indirect_streambuf.hpp all previously existing tests passed. I recommend adding the new tests in dual_seekable_test.cpp. I have created the ticket https://svn.boost.org/trac/boost/ticket/10561 Best regards Jorge

1 0

[thread] Specific old move semantics usage
by Vicente J. Botet Escriba 27 Sep '14

27 Sep '14

Hi all, I would like to remove the specific move semantics included in Boost.Thread as it was flawed. This has been replaced by the Boost.Move one long time ago. Is there someone still using it? Could I at least define by the default (even for BOOST_THREAD_VERSION 2) BOOST_THREAD_USES_MOVE for Boost 1.57? Best, Vicente

2 1

[Modularization] Range and Spirit dependencies
by Stephen Kelly 27 Sep '14

27 Sep '14

Hello, Boost 1.55 has been out for some weeks. I repeat my recommendation to remove the Boost.Algorithm dependency from Boost.Range and the Boost.Serialization dependency from Boost.Spirit. http://thread.gmane.org/gmane.comp.lib.boost.devel/251966/focus=252090 http://thread.gmane.org/gmane.comp.lib.boost.devel/251966/focus=251968 http://thread.gmane.org/gmane.comp.lib.boost.devel/252250/focus=252293 Thanks, Steve.

3 7

questions regarding dependency reports(s)
by Robert Ramey 27 Sep '14

27 Sep '14

I've been looking at the question of "dependencies" and I would like to know a little more about how they are generated. I've looked at: a) http://www.pdimov.com/tmp/report-6d1f271/serialization.html b) http://www.steveire.com/boost/2014sept16_serialization.png c) bcp documentation And it doesn't seem that they all produce the same list of dependencies. a) doesn't include any *.cpp files. So I assume that it contains less than the true number of dependencies. That is if a *.cpp file includes a header as part of it's implementation and not it's interface, it wouldn't be included. b) produces a very intimidating graph. I'm not sure what the rules are for it's generation. I'm guessing that it uses dependencies at the library level rather than the *.cpp level which might make things look worse than they are. c) BCP seems pretty exhaustive in that it cans all the code in all the *.cpp libraries, tests, examples etc. For lots of applications - e.g. if I wanted to include a boost library with my application but not all the tests, It would generate a likely much larger subset than I need. But maybe not. If my application includes the boost library.dll then I guess I have to include it all. This raises an interesting question to me. Suppose I want to distribute my app with source and I include a CMake which just doesn't build the libraries but just includes the relevant *.cpp files in the application build itself? This would make my application depend upon the smallest subset of boost possible. What would it take to make a version of BCP which, given an arbitrary group of source files, returns a list of headers and *.cpp files which could be used to build the app? We know from an intuitive basis that we want to give the option of delivering a smaller boost, but we've always thought that that means delivering a library subset. Is this really what we want? What would users do with the smaller subset? (Besides complain that its not small enough?) How about if we tweaked BCP to deliver just a subset of files relevant to the target? Would that make them happier? Would it get us off the hook for trying to "solve" what the dependencies are? Just thinking out loud here. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-dependency-reports-s… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 8

Re: [boost] Stefanus Du Toit
by Hartmut Kaiser 26 Sep '14

26 Sep '14

http://emlakdanismanlari.com/izvusl/xqwkkozimojmnoisxjsllmsfkjpoaiycejluiocg

1 0

New C++14 config macros - opinions wanted
by John Maddock 25 Sep '14

25 Sep '14

There is a pull request to add new config macros for C++14 features (https://github.com/boostorg/config/pull/39) I have a few questions really, particularly for those more familiar with C++14 than me: * Do we need these? * Are these the correct names? * Are the proposed tests correct? Thanks, John.

8 9

TravisCI and Coverall usage policies in Boost
by Antony Polukhin 25 Sep '14

25 Sep '14

Hi, Motivation. I'd like to show some useful stuff using the Boost.Variant library as an example. Take a look at this link: https://coveralls.io/builds/1224886 It shows tests coverage and has a nice interface to get info about untested things. For example: * if we take a look at this https://coveralls.io/files/293662719 , we'll see that `polymorphic_get` was not tested for extracting type that is not in a variant variable * if we take a look at this https://coveralls.io/files/293662720 we'll see that swapping of recursive wrappers was not tested All that stuff was achieved by adding the https://github.com/apolukhin/variant/blob/travisci/.travis.yml file and turning a switch at coveralls.io site. Now let's take a look at the regression tests of variant: http://www.boost.org/development/tests/master/developer/variant.html . There we can see a indirect_travisci_tests tester. There's nothing special about that tester, except the fact that results are gathered using foreign TravisCI service. We can integrate foreign service to do regression reporting for us. We can even make this separately for each of the Boost libraries, triggering test run on every commit and reporting the results directly to README.md file (for example https://github.com/apolukhin/Boost.DLL#test-results) The problem. A few things make me nervous. First of all, TravisCI requires some access permissions to the repo. I'm not a github expert so I'm not 100% sure that this is safe. Second one, is that there is no policy in Boost about usage of foreign services like TravisCI and Coveralls. The questions. Is is OK to commit to Boost repos .travis.yml files without enabling TravisCI runs? Do we need a license note in .travis.yml file? Can we enable automated testing using TravisCI for a Boost repo? Can we enable automated tests coverage using Coverall for a Boost repo? -- Best regards, Antony Polukhin

5 9

[modularization] Extract xml_archive from serialization
by Stephen Kelly 25 Sep '14

25 Sep '14

Hi there, The biggest single problem of coupling in boost comes from the spirit dependency in the serialization library. This makes serialization itself very (and needlessly) heavy: http://www.steveire.com/boost/2014sept16_serialization.png Spirit is used only by the xml archiving classes. I recommend extracting an xml_archive library from serialization. That way, serialization no longer depends on spirit, which is already an improvement: http://www.steveire.com/boost/2014sept16_serialization-after-extract-xml_ar… Further, the serialization classes for boost::variant and boost::array are in the serialization library. This is not appropriate, as the serialization classes for all other types are in the libraries providing the types. Move the serialization classes to those libraries. mkdir ../variant/include/boost/serialization mv include/boost/serialization/variant.hpp ../variant/include/boost/serialization mkdir ../array/include/boost/serialization mv include/boost/serialization/array.hpp ../array/include/boost/serialization This is a large improvement: http://www.steveire.com/boost/2014sept16_serialization-after-type-move.png There is more that can be done. These things can be done now. I recommend doing them. Thanks, Steve.

8 23

[modularization] Are modular releases a goal or a non-goal?
by Stephen Kelly 25 Sep '14

25 Sep '14

Hello, I can download one monolithic tarball to get Boost 1.56: http://sourceforge.net/projects/boost/files/boost/1.56.0 And I get all of it. There are no separate 'modular Boost' tarballs so that I can download what I want and not what I don't. Compare to Qt which provides both monolithic source tarballs: http://download.qt-project.org/official_releases/qt/5.3/5.3.2/single/ and modular source tarballs: http://download.qt-project.org/official_releases/qt/5.3/5.3.2/submodules/ Is something similar to this a goal or a non-goal for 'Boost modularization'? Thanks, Steve.

10 32

[intrusive] Possible bug in bstree_algorithms.hpp
by Lars Hagström 25 Sep '14

25 Sep '14

Hi, I've just upgraded to boost 1.56 and I've run into a problem. I get an infinite loop inside insert_equal_lower_bound_check(...) in bstree_algorithms.hpp. I'm using that file indirectly through Boost.Interprocess. I've not been able to penetrate exactly what that function does or whether there is indeed a bug in it. But I did look at the version that was in 1.55 (called insert_equal_check_impl(...) there), and to me it looks like there is at least one unexpected change: A ! has been removed on the line where the branches are compared, which to me would mean that we put the wrong branch into x. Again, I don't really understand what is going on in that function, so I might well be completely wrong. Cheers Lars

2 22

[containers] Clarifications on incomplete type support?
by Mikael Persson 24 Sep '14

24 Sep '14

Hi all, I've been using Boost.Containers for some time now. As for many, the primary (and only) reason for using them (over STL ones) is that they support incomplete value types. Since the beginning, I have always assumed that support for incomplete value types meant that I could instantiate the container type and any indirect type, most notably, **iterators**. I cannot stress enough how important it is for data structure designs to be able to instantiate the iterators of containers of incomplete value types! And, in general, there is no inherent reason why, in general, incomplete type support could not extend to iterators as well. This is even more true in light of the SCARY iterator requirements (which boost containers purport to support, which cannot possibly be true given the compilation errors I have seen). So, my main question is this: Is the following code supposed to work when using Boost.Containers? boost::container::some_container<IncompleteType>::iterator it; The documentation only states that "all Boost.Containers containers [..] are designed to support incomplete types". This needs to be clarified when it comes to iterators, at least. If the above code is not guaranteed to work, then may I request that it be added to the requirements? Because in my view, not having iterator support for incomplete types sort of defeats the whole purpose of supporting incomplete types, except for the most trivial use-cases (like those "recursive containers" examples). And moreover, without this support, workarounds are so major that they won't benefit from the container's support for incomplete types any more (and therefore, might as well use the standard ones instead). >From experience, I know that most Boost.Container containers had working iterators for incomplete value types up to and including version 1.54 (and it's a kind of natural consequence of supporting incomplete types for the container itself). But recently, changes to the boost::container::list class have made it impossible to use of boost::container::list iterators for incomplete types (due to some convoluted new iterator scheme that I can barely understand myself). If iterators are supposed to be included in the incomplete type support, then this is a bug in the list container (and btw, boost::unordered_set also has the same problem), and I would also recommend adding this to the container unit-tests. Thanks, Mikael Persson

2 9

[modularization] What is a module? What is a sub-module?
by Vicente J. Botet Escriba 24 Sep '14

24 Sep '14

Hi all, After the long threads concerning the modularization it seems clear to me that we are in an impasse. While I guess breaking dependency cycles is a modularization goal for all of us, it seems that moving files from one module to a sub-module has not be well accepted, worst yet, could have some dramatic consequences (a lot of testers were broken with the MPL split) due to the way we build Boost. I'm wondering if we don't need an alternative definition of module/sub-module. This definition could be temporary, it would just be useful to identify the modules/sub-modules that would be the good ones. We could move the files when needed by some user oriented tools (install). Let me try it. A module or submodule is just a list of files. The first problem is how to identify this list. Currently, the boostdep tool request that a module is associated to the files in the directory include of a repository and a sub-module to the files in the directory include in a subdirectory of a repository. I don't remember which criteria Stephen Kelly is using in his tool. I propose to switch to a less restrictive and more explicit mapping that don't implies any change on how Boost is build/tested. The advantage is that we can change this mapping without any trouble on the regressions tests :) * If a repository don't have this explicit mapping, the module with the same name as the repository is composed of the files in the directory include, src and build of the repository. There could be other implicit modules for test, examples, benchmarks, ..., which are not user oriented. * If a repository has this explicit mapping, the module/sub-modules are the ones described in this mapping. Open points * Do we want/need to be able to define modules containing files in more than one repository? * Where the explicit mapping should be stored? * Should we track the build dependencies? How? * Should we rethink how Boost is build in a modularized world? * Do we want/need to take in account optional dependencies from the beginning? Note that this would not reduce the dependencies at the file level, but at least would help us to break the cycles. Peter, if we agree this is the way to exit from the impasse, would you like to adapt your tool to use an explicit mapping ? Any concrete proposal about how Boost could be installed in a modularized world would be welcome. Open point: Is anyone interested in working on this modular installation? Best, Vicente

8 16

Re: [boost] [Boost.Config] variadic templates availiable with GCC 5 in C++03 mode
by Lars Gullik Bjønnes 24 Sep '14

24 Sep '14

(resent due to missing membership on boost list) On 23 September 2014 22:43, Lars Gullik Bjønnes <larsbj(a)gullik.org> wrote: > Hi, > > It seems that the checking to define BOOST_NO_CXX11_VARIADIC_TEMPLATES or not > is slightly wrong when __GNUC__ > 4 (in this case __GNUC__ == 5) > > This was tried fixed in [SVN r70019], but it looks like the fix was > wrong for __GNUC__ > 4. > > (git 050da29d47ce43b1dca6bed03d54c40d5e3d315e) > > > This is the current code: > > // Variadic templates compiler: > // http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html > # if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == > 4) && \ (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > # define BOOST_HAS_VARIADIC_TMPL > # else > # define BOOST_NO_CXX11_VARIADIC_TEMPLATES > # endif > #endif > > > This is my proposed fix: > > diff --git a/functional/boost/boost/config/compiler/gcc.hpp > b/functional/boost/boost/config/compiler/gcc.hpp > index ef6b07e..736e8ba 100644 > --- a/functional/boost/boost/config/compiler/gcc.hpp > +++ b/functional/boost/boost/config/compiler/gcc.hpp > @@ -157,7 +157,7 @@ > > // Variadic templates compiler: > // http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html > -# if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ > == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > +# if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == > 4 && __GNUC_MINOR__ >= 4)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) > # define BOOST_HAS_VARIADIC_TMPL > # else > # define BOOST_NO_CXX11_VARIADIC_TEMPLATES > > > (I'll post a none-damaged diff if wanted.) > > -- > Lgb -- Lgb

3 2

[iterator] Support other tuple implementations with zip_iterator
by Kohei Takahashi 24 Sep '14

24 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Here is my proposal [1] for supporting other tuple implementations (e.g. std::tuple) with zip_iterator, which discussed at the issue [2]. This PR will reimplement zip_iterator as a fusion based one, because current implementation is tightly coupled with Boost.Tuple. Of course, Boost.Tuple should be accepted via Boost.Fusion. [1] https://github.com/boostorg/iterator/pull/2 [2] https://svn.boost.org/trac/boost/ticket/7526 Thanks, Kohei Takahashi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUIi7FAAoJEGGyPxPRp/zof5IQAMFjfB1q3yhXXEvoXOZGedhn 8S6hCWsar0MA42Wn/PIG1cMxgb4oc9cZFv6KBieDAn38QJu44NYDFhxhRlMPDMrs cgNQDbvYROWzakzUX93DstzSwvUwqIjWg4bFFYbE5cmK1MbmCWZODs5TQFKQDxxO KfrUEsttoMlbklFa5Rw9JdM3bP2NMUlmJZ9M/8/rBhAf/AvgLiSK9f7qXjoWoMaZ DwZKEztQB2ZRL+iwtCeNJU0OSJ3/KCsS45xYKY9tsE25RGWU8vdryKEqt/eeHe/d dfVpMWMLKZ3g7PoLc73ntxX+C0B/Zj96rhqurt3Z6gtWmSiYFxct/0oDqfu9JKCn hG4p+g70m1nW47Kfvc8p3ZiWABvOOghPT9CEyyATh4nMzJTYLwawD00uRUtdATT9 siTIH2AeEHUnUuNHMMdbr7kJMq/6aubt0RFz04TgIZJ0EmrkjbuxfeiemoiZhyeN JNE9ubujqMiAcyeLpCWAbnogLWMgn8duvIKYc0pvFlYIkGWKrAMSd46RaCd47g4x alYh7vlLE8nqdmAwe2is5PfFIw8qzJj1zn+Kj+CFkXouJ9eObiOXTbTdQNPhFplT gAxYLdcmz23goQzAQ9xTMySmuGFzHKZn+uTQ3gpzDABC6zGCXhGA/Hu+JER/KmTY 3Ty2EoDqWdsu/bp9mY+/ =wJsr -----END PGP SIGNATURE-----

1 0

Boost.Hana - Type Classes, data types and categories (tags).
by Vicente J. Botet Escriba 23 Sep '14

23 Sep '14

Hi Louis, There is a lot of very good work on your library. I have some comments in relation on how I have implemented Type Classes in my prototype. About datatype<T>. The library proposes type classes and data types. The name datatype_t<> is confusing as the datatype<T> meta-functions must not return one of the defined data types. I see it much more as a category, which is used to map the data type to a category used as parameter of the instantiation TC::Instance<datatype_t<T>>. In addition, I wonder if the category associated shouldn't depend on the type class we want to map. TC::Instance<category_t<T, TC>> About naming: Haskell doesn't have namespaces and all the functions are at the same scope. Your library makes use of a lot of non-member functions, and so name clashing must be avoided. What about moving all the non-member functions of the Type Class to a specific namespace? E.g. struct Monad { ... }; namespace monad { using namespace applicatives; ... bind() }; The use would need to use the type class namespace explicitly auto x = monad::bind(m, f) or introduce the namespace of the type class using namespace monad; auto x = bind(m, f); Best, Vicente

4 10

CMake module for compile-time benchmarks
by Louis Dionne 22 Sep '14

22 Sep '14

Hi, While working on Hana, I have developped a couple of tools to generate compile-time benchmarks. I have now made this easier to use for anyone who wishes to do the same by writing a CMake module which does the dirty work for you. The module is available at [1]. Basically, you drop this in your CMake tree, install a couple of dependencies and then you can create targets to run the compile-time benchmarks. The gist of it is explained in the module, and you can find a lot of examples in [2]. This is still a work in progress. For example, the module still does not support runtime benchmarking even though the documentation says it does. Also, it only works with Clang and GCC for now. There are probably a ton of glitches and ways to improve it; feel free to send pull requests! Regards, Louis [1]: https://github.com/ldionne/hana/blob/master/cmake/Benchmarks.cmake [2]: https://github.com/ldionne/hana/tree/master/benchmark

1 0

Boost.Hana - Maybe and Either data types design
by Vicente J. Botet Escriba 21 Sep '14

21 Sep '14

Hi Louis, I have some concerns with the design of the Maybe and Either data types (maybe the other data types have the same design, I have not taken a look at). There are somethings that I don't understand, sorry I have not changed yet my mind to then new C++ way. If I want to define a function that takes an Either string int, how can I define it? void f(??? p) {} I see that there is a maybe_detail::maybe<bool,class>, however I don't think this is the data type of Maybe, is it? Anyway, I don't see a either_detail::either<bool, class, class>. I have the impression that I must use always auto with lambdas auto f = [](auto p) {...}; But I don't know what I can put in the body. It is to clear neither how can I declare a variable of type Either string int. I see that I can declare a Left string and a Right int BOOST_HANA_CONSTEXPR_LAMBDA auto left_value = left("x"); BOOST_HANA_CONSTEXPR_LAMBDA auto right_value = right(1); I have the impression that the variables are initialized only once and can not be reassigned,or at least we can not assing a Left value to a variable initialized with a Right value. Is this by design? A last concern related to the applicative lift function. I suspect that it corresponds to the Haskell return function and the more general unit Monad function. As there is a lift function in Haskell, this is a little bit confusing. I have named this function make :) In Haskell, the template parameter is a type constructor. This Monad(Applicative) type constructor should be Either E, not Either. Is the type-constructor feature missing from your design? How wan I create an Either string int with a call to auto x =lift<Either>(123); I would expect something like auto x = lift<Either<string>>(123); In my prototype I have auto x = make<expected<holder, string>>(123); where expected<holder, string> is the Monad type constructor for expected<T, string>. Sorry the argument of expected and Either are in interchanged. The string type is the Error. Best, Vicente

2 1

[GSoC] [Boost.Hana] Formal review request
by Louis Dionne 21 Sep '14

21 Sep '14

Dear Boost, It has been a while since I've given news about my GSoC project, Boost.Hana[1]. Things are going very well and I uploaded the library to the Boost Incubator. I think it is time to push the library forward for review. As the author, I know everything that's left to be done and polished before I can be fully satisfied. Still, I believe the library is worthwhile in its current state as it implements a superset of the functionality found in the Boost.MPL and Boost.Fusion. I also think the library will benefit greatly from a larger user base and more feedback. Here are some caveats: - The library requires a full C++14 compiler, so only Clang 3.5 can compile the unit tests right now. However, compilers will eventually catch up. Also, pushing cutting edge libraries forward might motivate compilers to support C++14 ASAP, which is probably a good thing. - The library is not fully stable yet, so interface changes are to be expected. I don't see this as a problem as long as this is documented, especially since I expect Hana to be used mostly for toying around for at least a while. I could be mistaken. So unless someone thinks the library isn't ready or would get rejected right away in its current state for reason X, I am requesting a formal review for Boost.Hana. Regards, Louis [1]: http://github.com/ldionne/hana

22 110

Re: [boost] proposal a movable_initializer_list
by 何子杰Hzj_jie 19 Sep '14

19 Sep '14

No body interests in it? I trust if the initializer_list is movable, it would be great helpful to construct a class with a set of lambda expressions. And we can use these lambda expressions to define a procedure, and provide a better solution for asynchronous programming. .Hzj_jie ________________________________ From: 何子杰Hzj_jie<mailto:hzj_jie@hotmail.com> Sent: ‎16/‎9/‎2014 10:35 To: boost(a)lists.boost.org<mailto:boost@lists.boost.org> Subject: Re: [boost] proposal a movable_initializer_list sorry, my fault of the mistake of for-range usage, you are correct, I am using iterator in my implementation. The efficiency I am taking care is the difference between copy-construction and move-construction. It will be significant if we are using lambda expression. Surely we still have something else to improve, say, provide the size of the vector at construction. The way using movable_initializer_list in the test case is not typical, indeed I am trying another not related issue. <the order of the move-constructions are not expected, i.e. line 46 will throw errors by g++, but no problem by msvc> Usually if a class A accept movable_initializer_list<T> as the parameter of a constructor, we only need A({T(), T()}), i.e. same as initializer_list. You properly would like to have a look at the event class, which is the typical scenario of movable_initializer_list, at https://github.com/Hzj-jie/osi/blob/master/delegates/event.hpp, with a test at https://github.com/Hzj-jie/osi/blob/master/utt_cases/delegates/event_test.h…. briefly it uses movable_initializer_list to avoid a copy of std::function instances, but can provide a way to call constructor with { } syntax. .Hzj_jie From: Sebastian Redl Sent: ‎Monday‎, ‎September‎ ‎15‎, ‎2014 ‎8‎:‎09‎ ‎PM To: boost(a)lists.boost.org On 15 Sep 2014, at 9:39, 何子杰Hzj_jie <hzj_jie(a)hotmail.com> wrote: > hi, all, > > So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, > > The implementation of T* overloads is something like > > movable_initializer_list<std::initializer_list<T*> x) > > { > > for(auto it : x) > > { > > assert((*it) != nullptr); > > v.push_back(std::move(**it)); > > delete *it; > > } > } Should be for (auto p : x) { v.push_back(std::move(*p)); delete p; } because of how for-range works. Seems an incomplete manual change from your published source. However, this is highly problematic because: - There is absolutely no way to make this exception-safe. The intended usage is obviously: SomeType st = { new Foo(123), new Foo(456), new Foo(789) }; But if any constructor here throws, a lot of memory is leaked, and destructors are not called. - If efficiency is your goal, I somehow doubt that an additional dynamic allocation per element for the initial list, then building a vector element by element, is the best way to achieve it. - The interface to this is just horrible. Looking at your test case, there is an absurd amount of boilerplate. Here’s what we really want: SomeType st{ Foo(123), Foo(456), Foo(789) }; Here’s what your thing forces me to do: auto pointers = { new Foo(123), new Foo(456), new Foo(789) }; SomeType st(pointers); // Absolute best case: no ambiguity in overload resolution - actually rather doubtful. If you do it that way, you might as well do it this way: Foo[] foos = [ Foo(123), Foo(456), Foo(789) }; // No dynamic allocation SomeType st(make_move_iterator(begin(foos)), make_move_iterator(end(foos))); More efficient, and you could make helpers that combine the make_move_iterator and begin/end calls to reduce boilerplate. > > While the implementation of T overloads is something like > > moveable_initializer_list<std::initializer_list<T> x) > { > > for(auto it : x) v.push_back(move(*it)); > } Again, that’s not how for-range works. What you want is for (auto&& e : x) v.push_back(std::move(e)); But that doesn’t actually work, because a std::initializer_list never gives you non-const access to its elements. I notice that your test case doesn’t test this constructor. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost incubator milestone
by Robert Ramey 19 Sep '14

19 Sep '14

The boost library incubator (www.blincubator.com) has received it's first Boost quality review for one of its submitted libraries. See the review here: http://rrsd.com/blincubator.com/reviews/?library_post_id=669 Hopefully this will motivate more people to submit their own reviews in advance of some formal review period. BTW - this review of this library (Compute) is very positive. Hopefully this will motivate other potential users to try out the library and make their own review. If the number of reviews reaches 5 I'll ask that the formal review for this library be expedited since, given such a head start, the review should be much simpler than starting from scratch. So I'm encouraging people who want to get the review process on a faster track to submit their own reviews as soon as they can find time. The Incubator has been progressing more slowly than I would hope. But progress is being made. Hopefully, this will continue to the point where it becomes and "overnight" success. Thanks to Denis Demidov for breaking the ice here. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-incubator-milestone-tp4667761.html Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] TravisCI and Coverall usage policies in Boost
by Marek Kurdej 19 Sep '14

19 Sep '14

Hi, > If we ever get Windows on Travis, I was surprised how good the MSVC > static analyser has become, and we should have a pass with that too. > FYI, there is a CI similar to Travis running MSVC-12.0, see https://ci.appveyor.com/. I've used it for a personal project, you can have a look at a sample configuration file using Boost libraries at https://github.com/mkurdej/bft/blob/develop/appveyor.yml. The only problem, there is only a 30-day free trial... Cheers, Marek Kurdej -- Ph.D. candidate

1 0

Trac spam report
by Joaquín M Lopez Munoz 19 Sep '14

19 Sep '14

https://svn.boost.org/trac/boost/ticket/10502 Thank you Joaquín M López Muñoz Telefónica

2 1

[regression] Debian-sid
by Suckow, Thomas J 18 Sep '14

18 Sep '14

Someone has been running regression tests on develop with the name “Debian-sid”, I believe they have a space in the path to the regression suite, which is causing it to fail. The job gets run like clockwork, shame that it isn’t uploading any useful results. Either the operator of this builder should change the path so that it does not have a space, or the regression suite should be updated to tolerate it. I tried once to figure out where in the test suite the path got mangled, but was unsuccessful, maybe someone more familiar with it could take a look? - Thomas

2 3

[type_traits] Modularization proposal
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, Boost.TypeTraits is used in lots of other Boost libraries, and it currently unnecessarily pulls MPL and TypeOf. The dependencies are introduced by just these two public headers: floating_point_promotion.hpp and common_type.hpp. I'd like to avoid these dependencies. I propose to extract common_type.hpp (and its implementation and tests) into a sublib within type_traits (e.g. type_traits/common_type). As for floating_point_promotion.hpp, it is used in promote.hpp, which is using integral_promotion.hpp. I can see two ways of tackling it: 1. Extract all promotion traits into a sublib (e.g. type_traits/promotion). This includes floating_point_promotion.hpp, integral_promotion.hpp and promote.hpp, as well as their tests. 2. Change floating_point_promotion.hpp to not use MPL. MPL is used only to workaround BOOST_NO_CV_SPECIALIZATIONS, which is defined for Borland 5.51 and older and MPW 8.90 and older. The simplest way is to drop the workaround, but at a quick glance it should be possible to retain it. I'm currently leaning towards the option 2, although we obviously don't test those compilers and there is no way of knowing if the code will still work after the change. So I'm interested to know others' opinion, both with regard to the general idea and the way of proceeding with floating_point_promotion.hpp in particular. PS: TypeTraits dependencies can be seen in the report Peter graciously uploaded: http://www.pdimov.com/tmp/report-d5ca5be/type_traits.html After the modularization efforts TypeTraits should only depend on Config, Core, Preprocessor, MPL.Core and StaticAssert. Don't mind that MPL.Core depends on MPL - the pull request fixing it has already been created.

8 23

[mpl] Modularization pull request
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, I've created this pull request: https://github.com/boostorg/mpl/pull/11 to separate core components of Boost.MPL to a sub-library. The intent of this pull request is to reduce dependencies added by MPL to its dependent libraries, when only the basic MPL components are required. In particular, it should help resolving circular dependency between MPL and TypeTraits. Please, have a look at the list of moved components and let me know if you have any comments.

4 18

[testing] mpl/core tests not visible
by Andrey Semashev 17 Sep '14

17 Sep '14

Hi, I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?

3 21

[TR1] Reming TR1? [was: Libraries failing across the board.]
by Beman Dawes 16 Sep '14

16 Sep '14

On Wed, Jul 9, 2014 at 8:13 AM, John Maddock <boost.regex(a)virgin.net> wrote: > > > On 08/07/2014 22:07, Beman Dawes wrote: > >> Marshall is just a few days away from being able to put out a beta release >> candidate. (And that is very good news!) >> >> But we still have too many libraries failing across the board on master: >> >> accumulators >> interprocess >> numeric/ublas >> pool >> proto >> spirit/repository >> spirit/test >> tr1 >> > > TR1 is now deprecated, and again hasn't been changed in a long time - the > main failures seem to be caused by changes to Boost.Random (or possibly > std::random) so that it is now no longer TR1 compliant. Someone would have > to rewrite it to use TR1-compatible random number classes perhaps culled > from an old version of Boost, frankly I just don't see the point. The lib > should probably be removed from Boost at some point. > We went back and forth a bit, and decided to remove TR1 after 1.56.0 shipped. What exactly needs to be done? * Remove the .gitmodules entry. * Remove the status/Jamfile.v2 entry. * Remove the libs/maintainer.txt entry. * Update http://www.boost.org/doc/libs/ Anything else? --Beman

5 4

[modularization] mplcore depends on mpl
by Stephen Kelly 16 Sep '14

16 Sep '14

Hi there, libs/mpl/core/include/boost/mpl/aux_/include_preprocessed.hpp from mplcore includes boost/mpl/aux_/config/compiler.hpp which is in mpl. mpl depends on mplcore. This is a circular dependency. I thought the point of the split was to resolve that in part. If so, then I recommend you go ahead and resolve the cycle in the obvious way. Thanks, Steve.

2 1

Re: [boost] proposal a movable_initializer_list
by 何子杰Hzj_jie 16 Sep '14

16 Sep '14

sorry, my fault of the mistake of for-range usage, you are correct, I am using iterator in my implementation. The efficiency I am taking care is the difference between copy-construction and move-construction. It will be significant if we are using lambda expression. Surely we still have something else to improve, say, provide the size of the vector at construction. The way using movable_initializer_list in the test case is not typical, indeed I am trying another not related issue. <the order of the move-constructions are not expected, i.e. line 46 will throw errors by g++, but no problem by msvc> Usually if a class A accept movable_initializer_list<T> as the parameter of a constructor, we only need A({T(), T()}), i.e. same as initializer_list. You properly would like to have a look at the event class, which is the typical scenario of movable_initializer_list, at https://github.com/Hzj-jie/osi/blob/master/delegates/event.hpp, with a test at https://github.com/Hzj-jie/osi/blob/master/utt_cases/delegates/event_test.h…. briefly it uses movable_initializer_list to avoid a copy of std::function instances, but can provide a way to call constructor with { } syntax. .Hzj_jie From: Sebastian Redl Sent: ‎Monday‎, ‎September‎ ‎15‎, ‎2014 ‎8‎:‎09‎ ‎PM To: boost(a)lists.boost.org On 15 Sep 2014, at 9:39, 何子杰Hzj_jie <hzj_jie(a)hotmail.com> wrote: > hi, all, > > So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, > > The implementation of T* overloads is something like > > movable_initializer_list<std::initializer_list<T*> x) > > { > > for(auto it : x) > > { > > assert((*it) != nullptr); > > v.push_back(std::move(**it)); > > delete *it; > > } > } Should be for (auto p : x) { v.push_back(std::move(*p)); delete p; } because of how for-range works. Seems an incomplete manual change from your published source. However, this is highly problematic because: - There is absolutely no way to make this exception-safe. The intended usage is obviously: SomeType st = { new Foo(123), new Foo(456), new Foo(789) }; But if any constructor here throws, a lot of memory is leaked, and destructors are not called. - If efficiency is your goal, I somehow doubt that an additional dynamic allocation per element for the initial list, then building a vector element by element, is the best way to achieve it. - The interface to this is just horrible. Looking at your test case, there is an absurd amount of boilerplate. Here’s what we really want: SomeType st{ Foo(123), Foo(456), Foo(789) }; Here’s what your thing forces me to do: auto pointers = { new Foo(123), new Foo(456), new Foo(789) }; SomeType st(pointers); // Absolute best case: no ambiguity in overload resolution - actually rather doubtful. If you do it that way, you might as well do it this way: Foo[] foos = [ Foo(123), Foo(456), Foo(789) }; // No dynamic allocation SomeType st(make_move_iterator(begin(foos)), make_move_iterator(end(foos))); More efficient, and you could make helpers that combine the make_move_iterator and begin/end calls to reduce boilerplate. > > While the implementation of T overloads is something like > > moveable_initializer_list<std::initializer_list<T> x) > { > > for(auto it : x) v.push_back(move(*it)); > } Again, that’s not how for-range works. What you want is for (auto&& e : x) v.push_back(std::move(e)); But that doesn’t actually work, because a std::initializer_list never gives you non-const access to its elements. I notice that your test case doesn’t test this constructor. Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Darwin Clang Config failures.
by John Maddock 15 Sep '14

15 Sep '14

Does anyone understand why these all fail: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… Is <functional> really broken on that platform? Surely not? Thanks, John.

4 3

proposal a movable_initializer_list
by 何子杰Hzj_jie 15 Sep '14

15 Sep '14

hi, all, the initializer_list in c++11 does not support the inner objects to be moved, so in some scenarios the performance will be significant impacted. say, an event class, which stores several std::function objects, and execute them later. the prototype is template <typename Args…> class event { private: std::vector<std::function<void(Args…)>> v; public: event(std::initializer_list<std::function<void(Args…)>>); void bind(std::function<void(Args…)>&&); }; When calling the constructor of event with a set of lambda expressions, the std::function objects will be copied instead of moved, and cause performance impact. Though pointer can resolve the issue, the syntax is not friendly, and the user needs to delete the instances manually. So I proposal a movable_initializer_list, it accepts two ways to construct, with an initializer_list<T*> or initializer_list<T>, the prototype is, template <typename T> class movable_initializer_list { private: std::vector<T> v; public: movable_initializer_list(std::initializer_list<T*>); movable_initializer_list(std::initializer_list<T>); // other functions same as initializer_list }; The implementation of T* overloads is something like movable_initializer_list<std::initializer_list<T*> x) { for(auto it : x) { assert((*it) != nullptr); v.push_back(std::move(**it)); delete *it; } } While the implementation of T overloads is something like moveable_initializer_list<std::initializer_list<T> x) { for(auto it : x) v.push_back(move(*it)); } Surely end-users need to aware the implementation of movable_initializer_list will move the objects instead of copy. The full implementation is at https://github.com/Hzj-jie/osi/blob/master/formation/movable_initializer_li…, and the test is at https://github.com/Hzj-jie/osi/blob/master/utt_cases/formation/movable_init…. Please feel free to give me some suggestions about this proposal. Thank you in advanced. .Hzj_jie

2 1

[vmd] Library Review
by Paul Mensonides 15 Sep '14

15 Sep '14

(apologies for the late review) -- Design -- Many of the utility components of the library have decent design. There are, however, a couple of aspects of the design that I dislike, and they touch on a large chunk of the library. These concerns all revolve around the registration, recognition, parsing, and limitations of various "v-types" and "v-sequences". I do not yet see a strong use case for the "v-key"/"v-identifier" recognition scenario, as opposed to just registering a "v-identifier". For example, #define BOOST_VMD_MAP_<v-key><v-identifier> // ... BOOST_VMD_IS_IDENTIFIER(<v-seq>, <tuple-of-v-keys>) Perhaps Edward can enlighten me about the use-cases for which this is ideal. I do see some use-cases, but in most cases it requires dispatch based on what the particular "v-identifier" it is anyway. One could do better for this low-level part with registrations such as (without a BOOST_VMD_ prefix for brevity) #define IDENTIFIER_CIRCLE (CIRCLE), #define IDENTIFIER_SQUARE (SQUARE), #define IDENTIFIER_TRIANGLE (TRIANGLE), #define IDENTIFIER_RECTANGLE (RECTANGLE), These definitions don't allow one to directly test for specific "v-identifiers", but they do allow one to extract registered "v-identifiers" from a "v-sequence". If all such registrations are required to be the same, there is no need for separate per-library prefixes. Macros can be defined multiple times if they are defined the same way. Similarly, the "v-numbers" could be pre-registered by the library as #define NUMBER_0 (0), #define NUMBER_1 (1), #define NUMBER_2 (2), // ... Tests for specific "v-identifiers" can be done via extraction from the above and using macro definitions such as #define COMPARE_CIRCLE_CIRCLE () #define COMPARE_SQUARE_SQUARE () // ... In many cases this sort of comparison is not needed, as one would directly dispatch off of the "v-identifier" itself. In any case, one could "parse" a "v-sequence" into "v-types" without many of the limitations of the current design. The following example uses Chaos, but I do not think there is anything in the design that fundamentally cannot be made to work on (e.g.) VC++. #include <chaos/preprocessor.h> #define NUMBER_1 (1), #define NUMBER_2 (2), #define NUMBER_3 (3), #define NUMBER_4 (4), #define NUMBER_5 (5), // ... // parser implementation... #define PARSE(vseq) PARSE_S(CHAOS_PP_STATE(), vseq) #define PARSE_S(s, vseq) \ CHAOS_PP_SPLIT(0, CHAOS_PP_EXPR_S(s)(CHAOS_PP_WHILE_S( \ s, PARSE_P, PARSE_O,, vseq \ ))) \ /**/ #define PARSE_P(s, seq, vseq) \ CHAOS_PP_COMPL(CHAOS_PP_IS_EMPTY_NON_FUNCTION(vseq)) \ /**/ #define PARSE_O(s, seq, vseq) \ seq CHAOS_PP_IIF(CHAOS_PP_IS_VARIADIC(vseq))( \ PARSE_O_A, PARSE_O_B \ )(vseq) \ /**/ #define PARSE_O_A(vseq) PARSE_O_A_A vseq #define PARSE_O_A_A(...) (3, (__VA_ARGS__)), #define PARSE_O_B(vseq) \ CHAOS_PP_IIF(CHAOS_PP_IS_VARIADIC(NUMBER_ ## vseq))( \ PARSE_O_B_A, \ CHAOS_PP_IIF(CHAOS_PP_IS_VARIADIC(IDENTIFIER_ ## vseq))( \ PARSE_O_B_B, PARSE_O_B_C \ ) \ )(vseq) \ /**/ #define PARSE_O_B_A(vseq) \ (1, CHAOS_PP_REM_CTOR( \ CHAOS_PP_SPLIT(0, NUMBER_ ## vseq) \ )), \ CHAOS_PP_SPLIT(1, NUMBER_ ## vseq) \ /**/ #define PARSE_O_B_B(vseq) \ (2, CHAOS_PP_REM_CTOR( \ CHAOS_PP_SPLIT(0, IDENTIFIER_ ## vseq) \ )), \ CHAOS_PP_SPLIT(1, IDENTIFIER_ ## vseq) \ /**/ #define PARSE_O_B_C(vseq) (0, vseq), // registrations... #define IDENTIFIER_CIRCLE (CIRCLE), #define IDENTIFIER_SQUARE (SQUARE), #define IDENTIFIER_TRIANGLE (TRIANGLE), #define IDENTIFIER_RECTANGLE (RECTANGLE), PARSE( CIRCLE RECTANGLE (a, b, c) TRIANGLE 3 (xyz) UNREGISTERED SQUARE ) (Apologies for any mistakes in the above. I wrote it up quickly.) This particular example results in key-value pairs of the form: (0, <unrecognized>) (1, <v-number>) (2, <registered-identifier>) (3, <tuple>) (2, CIRCLE) (2, RECTANGLE) (3, (a, b, c)) (2, TRIANGLE) (1, 3) (3, (xyz)) (0, UNREGISTERED SQUARE) There are a number of things that could be done instead of producing a binary sequence like this (which Boost.Preprocessor cannot handle). One could fold the results via a user-supplied macro, for example. Aside from the massive amount of clutter introduced by workarounds, many of the pieces of the above are already available either in Boost.Preprocessor or in other parts of the VMD library. For example, BOOST_VMD_IS_EMPTY is essentially CHAOS_PP_IS_EMPTY_NON_FUNCTION. -- Implementation -- I have not looked closely at the implementation, but I do know what a herculean effort it is to get this type of stuff working with VC++ in particular. -- Documentation -- There are few inaccuracies in the documentation related to motivations for various Boost.Preprocessor things, but those could be fixed. The documentation for BOOST_VMD_IS_EMPTY is decent except that essentially any input that ends with a function-like macro name will cause weird results or errors. So much so that the documentation should just disallow input that ends with a function-like macro name across the board. Other than that, the documentation needs some clean-up and organization (particularly of definitions), but does a reasonable job of documenting the library. I do feel that a lot of documentation complexity comes from the way that v-keys/v-identifiers (etc) are handled. -- Usefulness -- There is a definite use-case for many of the utilities in the library, and the fundamental concept v-sequence parsing. -- Testing -- I tested the library with GCC and everything functioned as advertised. -- Effort -- I did a fairly significant study of the design and interface of the library. -- Domain Familiarity -- I had my skull opened up and had "preprocessor metaprogramming" tattooed directly onto my brain. -- There are many good parts of the library--including the herculean effort to make it work on sub-par preprocessors such as VC++. However, at this point I would be hesitant to recommend acceptance based on the design of the v-type recognition and v-sequence parsing part. I am open to argument about why the current design is superior based on use-cases or technical limitations introduced by (e.g.) VC++ or, if it is not superior, a further review at a later date after a redesign because the underlying concept is sound. -- Regards, Paul Mensonides

3 14

Intel C++ Linux non-commercial software development license updated information
by Edward Diener 15 Sep '14

15 Sep '14

Just a quick note to tell anyone interested that evidently Intel has discontinued their free Intel C++ Linux compiler for developers based on their non-commerical software development license. If you look at their non-commercial software development license page at https://software.intel.com/en-us/non-commercial-software-development you will see that it only potentially offers a license for academics and the response I received on their online forum for Intel C++ is that they have discontinued their non-commercial software development license for developers, although they seem loth to make an announcement about it or publicize it. I have some recent versions of Intel C++ Linux with which I can still test but I will not be able to test the latest version(s) of Intel C++ on Linux. The isocpp Get Started page at https://isocpp.org/get-started still mentions the free Intel C++ version, but this evidently is no longer the case.

1 0

[process] [sorting] [singularity] [compute] [others] Who needs review manager?
by Antony Polukhin 14 Sep '14

14 Sep '14

Hi, Library authors that have no review manager and feel ready for review please contact me via this mailing list. -- Best regards, Antony Polukhin

7 14

[serialization] [libstdc++] [detail] utf8_codecvt_facet fixes broke serialization test_array_xml_warchive
by Beman Dawes 13 Sep '14

13 Sep '14

The specific crash message is: *** Error in `../../../bin.v2/libs/serialization/test/test_array_xml_warchive.test/clang-linux-libstdcpp/debug/test_array_xml_warchive': double free or corruption (!prev): 0x00000000015f6f90 *** It occurs for clang, gcc, and intel compilers, using libstdc++. It does not occur with clang using libc++. It does not occur with msvc 10.0, 11.0, or 12.0. None of the other libraries (filesystem, log, program_options, property_tree) that use utf8_codecvt_facet are failing on develop. This is mainly a heads up to let people know that the serialization problem in develop is being worked on, but it may be a day or two before I have a fix. --Beman

4 10

[asio] RFC on new reliable UDP library
by Niall Douglas 12 Sep '14

12 Sep '14

Dear Boost and ASIO users, CC: boost(a)lists.boost.org, asio-users(a)lists.sourceforge.net I am writing to ask for comments on the design of and interest in a generic reliable messaging library based on ASIO. Such a library could bring to ASIO very considerably improved data transfer performance over TCP, plus the ability to ignore NAT firewalls. The design imperatives for such a library are proving tricky to reach consensus upon, so perhaps the community might be able to help. Firstly, what features should such a reliable messaging library have? Here are some for you to consider: * Should it have wire transport backends with an abstraction from wire transports, so a UDT backend could be interchangeable with TCP for example with just a recompile needed? Upper level code need therefore not consider what format the wire transport takes, just that messages are reliably delivered or we are told of the connection failure. Some mechanism for dealing with out of order messages, and message expiry in case congestion control excessively delays outbound messages would also be included. You should be aware that congestion control for a reliable messaging library means one has no choice but to pace message construction (i.e. block/EWOULDBLOCK handing out new message send templates), otherwise one ends up buffering more data for sending than potentially can ever be delivered. This is because we cannot drop reliable messages, nor can we pace writes, so pacing new message construction is the only alternative. * Should it be zero copy for both receipt and send? If so, we'll have to break with the existing ASIO API somewhat - namely that MutableBufferSequence will need to now become MutableFileOffsetBufferSequence so one can supply scatter/gathers of user space buffers and kernel side buffers. We'll also have to templatise the buffer management so client code can supply the virtualisation (e.g. an iterator) which remaps inbound message fragments into apparently contiguous regions. By the time we have done these, the API looks quite different. * Should it be written using C++ 14 idioms instead of the existing 03 idioms ASIO uses? If so, basing read and write handlers on the C++ 17 proposed experimental::expected<T, E> (http://www.hyc.io/boost/expected-proposal.pdf) makes much more sense than the fixed ASIO handler prototype void (*handler)(const boost::system::error_code& ec, std::size_t bytes_transferred) - it is more powerful, more expressive, optionally integrates cleanly with no-alloc future-promise and the rest of the C++ 11/14 STL, and lets handlers use any mix of error reporting mechanism they choose. It also opens the door to a much cleaner and tighter integration of the future C++ 17 Networking TS with Concurrency TS. Equally, especially if combined with the earlier changes, it goes further and further away from the present ASIO design. * How concurrent should it be capable of? Unlike TCP where it makes not much sense to have concurrent writers, UDP allows enormous parallelism, potentially into queue depths of thousands on decent NICs, sufficiently so where a strand based design may simply not scale. We believe that with some effort a completely lock free design which can make full use of the batch datagram send and receive APIs on Linux and Windows is possible - we believe that such a design would scale close to linearly to CPU cores available. Unfortunately, as batch datagram send/receive is not supported by ASIO and on POSIX the main dispatcher appears to be locked by a mutex, this would require a custom code path and i/o service. If combined with all of the above, it starts to look like a rewrite of the core of ASIO which seems very big just to implement reliable messaging. I guess that is good for now for starting discussion. My thanks for your time in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

9 17

[core/noncopyable][test/boost::unit_test::singleton] massive test failures
by Joaquin M Lopez Munoz 11 Sep '14

11 Sep '14

Hi, There's a problem with noncopyable and boost::unit_test::singleton in Intel 13 for Linux in C++11 compatibility mode that's rippling through many Boost libs. To list a few: date_time: http://tinyurl.com/lkeakab geometry: http://tinyurl.com/n3rajyn regex: http://tinyurl.com/kxkqo4c tuple: http://tinyurl.com/oz3vlct The error messages go like protected function "boost::noncopyable_::noncopyable::noncopyable()" [...] is not accessible through a "boost::noncopyable_::noncopyable" pointer or object[...] protected function "boost::unit_test::singleton<Derived>::singleton()" [...] is not accessible through a "boost::unit_test::singleton<boost::unit_test::unit_test_log_t>" pointer or object[...] which are manifestations of the following compiler bug: https://software.intel.com/en-us/forums/topic/404755 The report also indicates a simple workaround consisting of replacing BOOST_CONSTEXPR noncopyable() = default; with noncopyable() {} (seemingly, this would also fix boost::unit_test::singleton automatically.) Maybe the maintainer of boost:noncopyable can try a fix for ICC 13 along these lines? This can potentially clear a ton of yellow cells. I'd volunteer a pull request but alas I don't have local access to that compiler. Thank you, Joaquín M López Muñoz Telefónica

8 38

[build] clang objective c support?
by Emil Dotchevski 11 Sep '14

11 Sep '14

Hello, It seems like building with the clang-darwin toolset silently ignores .m and .mm files What is the status of Objective C support in this toolset? Is this a configuration problem on my part or is it just not supported? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

3 6

ICL space and running complexity
by Kenneth Adam Miller 11 Sep '14

11 Sep '14

With regards to the ICL data structure, can anybody tell me what the space and time complexity is of the various interval_map types (split and regular)? http://www.boost.org/doc/libs/1_56_0/libs/icl/doc/html/index.html

2 1

[git] Problem after deleting submodule
by Edward Diener 10 Sep '14

10 Sep '14

Git is starting to get to me. I did a git pull from the latest master only to get a bunch of conflicts from the latest align submodule. I have never touched the align submodule locally so having conflict errors with it is absurd. After trying to straighten out the errors via a 'git reset --hard' for the align submodule, and still getting conflicts, I deleted the submodule locally just so I could get the latest master. Now I can't seem to get back the submodule. No matter what I do the submodule is no longer recognized at the top level. What do I do ? Yes git is powerful but it is also a VCS from hell. About the only intelligent thing I have ever heard Linux Torvalds say.

1 1

Trac spam report
by Joaquin M Lopez Munoz 09 Sep '14

09 Sep '14

I got this one: https://svn.boost.org/trac/boost/ticket/10437 Joaquín M López Muñoz Telefónica

5 6

_MSVC_VER - variadic_slot_invoker.hpp
by Anders Dalvander 09 Sep '14

09 Sep '14

There appears to be two predefined macro spelling mistakes in signals2/detail/variadic_slot_invoker.hpp. It says _MSVC_VER where it should say _MSC_VER. #if defined(_MSVC_VER) // <-- Here # pragma warning(push) # pragma warning(disable:4100) // unreferenced formal parameter #endif ... #if defined(_MSVC_VER) // <-- ... and here # pragma warning(pop) #endif Regards, Anders Dalvander

1 0

[range] Interest in range_call function?
by Arthur Rosenstein 09 Sep '14

09 Sep '14

Hi, I'm checking to see if there's interest in a range_call function that makes calling iterator-based algorithms with ranges a little less painful. Simply put, range_call takes a function and an argument list and forwards the arguments to the function while expanding ranges into begin/end iterator pairs. For example: range_call(std::sort, vec, std::greater<int>()); It can also transform the result a la Boost.Range: range_call(std::copy, range_call<return_begin_found>(std::unique, range_call<return_begin_end>(std::sort, vec) ), std::ostream_iterator<int>(std::cout, " ") ); Obviously, Boost.Range provides a cleaner interface for most standard algorithms. range_call, however, works with arbitrary functions and has a smaller surface area. Is there any interest in this (possibly as part of Boost.Range)? -- Cheers, Arthur

1 0

Re: [boost] [process] [sorting] [singularity] [compute] [others] Who needs review manager?
by Antony Polukhin 09 Sep '14

09 Sep '14

2014-09-08 22:52 GMT+04:00 Kyle Lutz <kyle.r.lutz(a)gmail.com>: > On Mon, Sep 8, 2014 at 9:03 AM, Antony Polukhin <antoshkka(a)gmail.com> > wrote: > > Hi, > > > > Library authors that have no review manager and feel ready for review > > please contact me via this mailing list. > > Hi Antony, > > The Boost.Compute library [1] is in need of a review manager. Also, > would it be possible to add it to the review queue listed at [2]? > > Thanks, > Kyle > > [1] https://github.com/kylelutz/compute > [2] http://www.boost.org/community/review_schedule.html > I took a quick glance at the library and it looks really interesting and promising. I'm not an expert in a problem domain, but at least I have some experience with CUDA. I'll need a few weeks to look through the sources and ask questions. If no one objects, after that we could discuss a review date and put it to the schedule. -- Best regards, Antony Polukhin

1 0

How to respond to mailing list
by Kirk Liberty 08 Sep '14

08 Sep '14

Hello, I'm sorry to have to ask this, but I've googled all around and can't figure it out. My email is set up to receive periodic digests of the mailing list. If I want to respond to an email thread, how would I do that? Thanks, Kirk

4 3

NTCTS Iterator [was: Interest in is_iterator type trait?]
by Beman Dawes 08 Sep '14

08 Sep '14

On Tue, Aug 19, 2014 at 1:56 PM, Peter Dimov <lists(a)pdimov.com> wrote: > Beman Dawes wrote: > > Source can be a iterator to a NTCTS or a container. >> > > An iterator to an NTCTS? That's an interesting invention. :-) > See http://beman.github.io/ntcts_iterator/ or https://github.com/Beman/ntcts_iterator --Beman

9 18

[Boost-users] Testers required
by Antony Polukhin 08 Sep '14

08 Sep '14

Hi, There is a big need in testers that have access to exotic platforms(zArch, MIPS) and compilers (Cray, IBM xlc ...). Could you please run `b2` in `boost/libs/type_index/test` and report results. This will help to test Boost.TypeIndex library and other libraries that depend on `demangle.hpp` I'll appreciate any help. Thanks in advance! -- Best regards, Antony Polukhin

2 2

Help identify the conversion bug in MSVC
by Andrzej Krzemienski 08 Sep '14

08 Sep '14

Hi, I found a bug in MSVC 10.0 that causes a bug in Boost.Optional. I will be trying to find a workaround for the compiler. I would like to ask people with the access to MSVC 11.0 and 12.0 to check if the bug also persist in these newer releases. The following code is expected to compile: struct A { A(int) {} A(A &&) {} }; struct B { operator A() { return A(1); } operator int() { return 0; } }; int main() { A t = B(); } The following code is expected *NOT *to compile: struct A { A(int) {} }; struct B { operator int() { return 0; } }; int main() { A t = B(); } Please let me know what your compiler says. Thanks, &rzej

2 2

Re: [boost] Finite state machine
by arcolight 07 Sep '14

07 Sep '14

> Hi, > I don't know if you're using msm or statechart but msm uses no dynamic > memory, except if you choose to use the event queue or deferred events. And > even this can be avoided by providing as template argument you own queue. > If you don't require these features, you can disable them. > > Cheers, > Christophe I'm using MSM. Yes I tried this, but I could not do so. Perhaps, I doing something wrong. Problem in that i've no OS, and even no full C library, I'm using newlib-nano. I was trying to disable everything, that I can, but this didn't help. I understand, that this situation is special and boostmust count on something. May be you can advise me how to use (and, may be,build?)boost with arm-none-eabi compiler.I've read docs and trying to build boost for arm-none-eabi, but compilation fails. Do I understand correctly, that MSM doesn't need to compile something - this is only .hpp files and it doesn't use libs, so I can try to use it without compilation? -- arcolight

2 1

[git][align][litre] git submodule update failure.
by Mostafa 07 Sep '14

07 Sep '14

$ git submodule update libs/align fatal: reference is not a tree: d32353ea7d39c0237202e3e460f3248f226db274 Unable to checkout 'd32353ea7d39c0237202e3e460f3248f226db274' in submodule path 'libs/align' $ git submodule update tools/litre fatal: reference is not a tree: 564d4d8d30b7e03ac5e25d78e14d2c19fa321c83 Unable to checkout '564d4d8d30b7e03ac5e25d78e14d2c19fa321c83' in submodule path 'tools/litre' According to this: http://stackoverflow.com/questions/13425298/git-submodule-update-fatal-erro… , this is most likely a maintainer's bug. From the above: "This is the most common problem with submodules. The commit that you are on in the outer repository has a reference to a commit in the submodule that someone did not push up yet. It's a dependency problem. Always push from the inside-out. This is most likely not something you did wrong, but someone else that's working in the repository. They were sloppy and forgot to issue push on the submodule and just pushed the containing repository. Stuff works on their machine because they made the change and those commits exist there." Is this true?

3 3

Re: [boost] Finite state machine
by arcolight 07 Sep '14

07 Sep '14

> Are you using Statechart or MSM? > -- Michael Caisse ciere consulting ciere.com I tried to use both. -- arcolight

1 0

Re: [boost] Finite state machine (arcolight)
by arcolight 07 Sep '14

07 Sep '14

> This is something that would be very interesting to me, but I wonder if the > memory allocation can be factored out in the current boost library by using > allocators or something. I'm not terrible familiar with the libraries > internals, but I'd be willing to take a look at my next free cycle. To be > clear, is there another state machine lib in boost besides > boost.statechart? That's the only one I'm familiar with from a user > perspective. > > -Greg Yes, custom allocator doesn't solve the problem, especially because current FSM-s includes many other libraries. In any case, I can't afford to use even custom allocator in my project, if I would use it, I must have sufficient size heap, it's risky in embedded system. I already have third-party code, that uses heap, and I couldn't do anything with it. :) Another FSM implementation - Boost.MSM(Meta state machine), I tried to use it in different ways, but i've failed. MSM based on MPL boost library. If you interested in code, I have small repo on github: https://github.com/arcolight/ecl, there are several small classes, one of them, in fsm.hpp - state machine. There are simple test with cd-player like in boost lib.

1 0

Finite state machine
by arcolight 07 Sep '14

07 Sep '14

Hi all. I have a question about participation in boost libraries. In my embedded project I'm using finite state machine and I tried to use one of the boost implementations of FSM, but they are too big and complex. Main disadvantage of them is usage of dynamic memory allocation, that I can't afford on my CPU and many dependencies, that I can't use on my CPU. CPU is ARM Cortex-M4 with 128K memory, I've no operating system in my project. I have write my own FSM implementation without dynamic memory and dependencies, it's more simple, than boost libraries, but, of course, not so powerful. I've used C++11 standard, specifically variadic templates. My question - Is there some interest in such FSM implementation for boost developers? I'll be very grateful for advice. P.S.: I'm sorry for my english, it's not my native language.

4 3

Autolinking broken in master
by Agustín K-ballo Bergé 06 Sep '14

06 Sep '14

There's a report that autolinking is broken for a fresh recursive checkout of master, due to b2 generating 1.57 libraries while boost/version.hpp still reports the version as 1.56. This commit setting BOOST_VERSION in Jamroot made it to master: https://github.com/boostorg/boost/commit/d9cf98c2074cf8a27017170375c5c825e4… While the corresponding commit for boost/version.hpp didn't: https://github.com/boostorg/config/commit/34e1c7416be2ede7d86f3dcc093a84580… Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

1 0

[iterator] Merge to master
by Andrey Semashev 06 Sep '14

06 Sep '14

Hi, There were lots of changes to Boost.Iterator develop in the last few months. The tests look green for quite some time now. Could these changes be merged to master? I need those changes to merge next/prior in Boost.Utility.

2 1

sqlpp11, 3rd iteration
by Roland Bock 04 Sep '14

04 Sep '14

Dear Boosters, Quite a bit has happened since last I reported about sqlpp11 in this forum [1,2]. I have incorporated a lot of the feedback you gave me, hopefully bringing the library closer to a reviewable state. Source: https://github.com/rbock/sqlpp11 Doku: https://github.com/rbock/sqlpp11/wiki (not at all formal yet) I am hoping for more feedback both here and live at CppCon (http://sched.co/1r4lue3) Here are some noteworthy changes: _Restructuring:_ The code has undergone a major restructuring, leading to a much simpler and thereby much more flexible way to define the structure of SQL statements. As a result, it would now be quite simple to add vendor specific features sqlpp11 connector libraries. Dominique Devienne mentioned array binding for inserts, Johan Baltié mentioned hierarchical searches (both features of Oracle). If you are interested in writing a connector and adding such features, please let me know, I'll walk you through it. _NULL handling:_ Enabled by the restructured code and spurred by the library quince by Michael Shepanski, sqlpp11 can now calculate which result fields can or cannot be NULL. Speaking of which, handling NULL for result values has been discussed a lot. The library now has compile-time configurable behavior, you can choose between an std::optional-like interface and mapping NULL to the trivial value of the result type, e.g. 0 for numbers or "" for strings, see also https://github.com/rbock/sqlpp11/wiki/NULL _Connectors:_ Matthijs wrote a new postgresql connector from scratch, see https://github.com/matthijs/sqlpp11-connector-postgresql The sqlite3 connector received a bunch of corrections, thanks to dirkvdb _Compilers:_ Known to compile with clang>=3.1 and gcc>=4.8. I currently cannot test with MSVC or Intel or others, but if you happen to have the latest top notch version of any of those, I'd be interested in what they have to say about sqlpp11. Cheers, Roland [1]: http://lists.boost.org/Archives/boost/2013/11/208388.php [2]: http://lists.boost.org/Archives/boost/2014/02/211206.php

7 43

[move][unique_ptr] c++14 unique_ptr comes to town
by Ion Gaztañaga 03 Sep '14

03 Sep '14

Hi to all, We've discussed about a boostified version of std::unique_ptr several times in later years. I decided we could not continue with this hole in the Boost toolset and implemented in Boost.Move a unique_ptr that follows the C++14 interface. Commit here: SHA-1: e1da7c5ca1162841f643331af891a9a730eba118 http://github.com/boostorg/move/commit/e1da7c5ca1162841f643331af891a9a730eb… This implementation is also usable from C++03, and apart from the general limitations of the Boost.Move machinery, it should be really uesful for C++03 users. I would like to make this implementation the official boost::unique_ptr implementation, but until the community approves this, it's in boost::movelib namespace (boost::move it's a function so I needed to tweak the namespace name). I would like to thank Howard Hinnant for his great public implementation of the emulated unique_ptr published here: http://home.roadrunner.com/~hinnant/unique_ptr03.html I've ported and refactored Howard's extensive testsuite to implement boost test cases. Really useful to detect many implementation errors and details. I've found unique_ptr much harder to write than I expected. The standard text is really detailed and helps implementors, but things like allowed conversion between pointers and deleters and several ICEs and different SFINAE parties on many compilers made the work quite entertaining. The API is taken from the draft n3797 and the implementation has some differences with the standard. The main reason for this is that I wanted to make unique_ptr as lightweight as possible avoiding external dependencies, as it's interesting to implement idioms like PIMPL. Main attributes and differences with the standard: -> Implemented in two headers: <boost/move/unique_ptr.hpp> and <boost/move/make unique.hpp>. -> <boost/move/unique_ptr.hpp>: Boost.Move is the only heavyweight dependency. Not even that, as unique_ptr.hpp only uses boost/move/utility_core.hpp, that does not depend on any external library excepct BoostConfig and StaticAssert. No TypeTraits, MPL and others. Only Boost.Config, BOOST_STATIC_ASSERT and BOOST_ASSERT are used in the implementation. No standard library headers used (no pointer_traits, memory or other utilities). -> <boost/move/make unique.hpp>: Boost.PP is used in compilers without variadic templates. This is the main reason to have a separate make_unique.hpp header and avoid pulling Boost.PP for c++03 users that only want to have C++11 unique_ptr. -> unique_ptr's "operator <" is implemented as x.get() < y.get() instead of std::less<CT>(). std::less requires <funcional>. std::common_type requires C++11 standard library or some partial emulation based on Boost.TypeOf. I don't think 99,99% of users will notice the difference. For raw pointers, in all our platforms comparisons provide strict weak ordering. If a smart pointer writer specializes std::less for its smart pointer, it should be a law against that. -> It's assignable from literal 0. I found some problems in some compilers trying to write a constructor for that. -> nullptr support is conditional on !defined(BOOST_NO_CXX11_NULLPTR) but I think really should have a Boost nullptr for C++03 compilers. Let's put Meyer's nullptr (http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/nullptr) in Boost for BOOST_NO_CXX11_NULLPTR compilers. -> unique_ptr<T[]> is convertible to other types when conversion is considered safe. This means that unique_ptr<T[]> is convertible to unique_ptr<const volatile T[]>. Conversion from T[] to U[] is considered safe if remove_cv<T> is the same type as remove_cv<U> and unique_ptr<T[]>::pointer is convertible to unique_ptr<U[]>::pointer. This is a feature that might go to C++17 (http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2118) Safe conversions in reset() and constructors from pointers are also implemented in unique_ptr<T[]>. I tested the implementation in GCC{4.4, 4.6, 4.7, 4.8} Clang3.4 and MSVC{7.1, 8.0, 9.0, 10.0, 11.0, 12.0} in 32/64 bits, debug/release and C++03/C++11 modes (where applicable). The class documentation is generated with Boost.Move documentation and the most part of it is taken from the standard. I haven't added a tutorial to Boost.Move but I plan to it based on Howard's c++03 unique_ptr tutorial. I hope you find this addition to Boost.Move useful. If you think the implementation is good enough to be the official boost::unique_ptr implementation living in Boost.SmartPtr, porting should be easy, except for the documentation part. That would require either combining somehow handwritten and Quickbook produced documentation or writing new docs for unique_ptr. Best, Ion

6 30

Default documentation settings
by Glen Fernandes 03 Sep '14

03 Sep '14

What is the value of chunk.section.depth used, for those Boost libraries whose documentation is supplied only in QBK form (not the generated HTML from the QBK)? It appears to be 1, i.e. my sections-within-sections are not broken into separate pages. If so, could we make the default <xsl:param>chunk.section.depth=2? Glen

2 4

Can't file issues on trac with Chrome
by legalize+jeeves＠mail.xmission.com 03 Sep '14

03 Sep '14

[Please do not mail me a copy of your followup] Attempting to file a bug report gives me this message: "Captcha Error Submission rejected as potential spam (StopForumSpam says this is spam (username)) Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following." ...but there is no captcha displayed in Chrome. If I attempt again in IE, then the captcha is displayed and I can enter the number and proceed. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

1 0

[fusion] Help co-maintaining Fusion modules
by Joel de Guzman 03 Sep '14

03 Sep '14

Hi Y'all, I need help in maintaining Fusion modules, especially those that are co-authored by someone else. For example, the Fusion Invoke module was authored by Tobias Schwinger who is unfortunately inactive now. I need help in maintaining the code, for instance, to adapt to C++11 and C++14. Case in point: https://svn.boost.org/trac/boost/ticket/10443 For that matter, I'd also like to take this opportunity to invite folks here to help out in some more aspects of the libraries I am involved with: Spirit, Fusion and Phoenix. If anyone is interested, please email me privately. THANKS! Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

1 0

[spinlock] concurrent_unordered_map is ready for review
by Niall Douglas 02 Sep '14

02 Sep '14

Dear Boost, CC: Howard, Jonathan for N3645 enhancements It has taken me far longer than I expected, however I believe that proposed boost::concurrent_unordered_map is ready for community feedback, with its unit test suite passing all green on the thread sanitiser and 92% coverage including exception safety tests. The main documentation page with the API and a lengthy explanation of the caveats in this design can be viewed at https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1c oncurrent__unordered__map.html Performance improves linearly to CPU cores at a slope of about 0.9. I only have four core hardware available to me, if someone could tell me how it scales to eight cores or more I would be very interested. Source code is at https://github.com/ned14/boost.spinlock. Tested on GCC 4.8, clang 3.4 and VS2013. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 13

Unable to find the boost.fsm library and turnstile example
by Aniket Pugaonkar 02 Sep '14

02 Sep '14

Hi, I wanted to implement a simple fsm using boost. i read the boost fsm doc http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html http://boost-extension.redshoelace.com/docs/boost/fsm/doc/reference.html but I couldnt locate the header files. Are the fsm library and other template classes located in boost statechart folder ? When I did a find in the subdirectories, I found this: boost version: 1.55 find . -name state_machine.hpp ./boost/msm/back/state_machine.hpp ./boost/spirit/home/support/detail/lexer/state_machine.hpp ./boost/statechart/state_machine.hpp ./libs/mpl/example/fsm/state_machine.hpp (1) Which one should I use to implement a simple FSM? (2) Also I couldnt find the turnstile example which they said is supposed to be in libs/fsm/examples/Turnstile folder. Can anyone please tell me the correct path and location ? [1]: http://boost-extension.redshoelace.com/docs/boost/fsm/doc/state_machine.html Regards Aniket -- Thanks and regards, Aniket Pugaonkar

2 3

Checking interest in DynamicLoad/DLL/DSO/Plugin library
by Antony Polukhin 02 Sep '14

02 Sep '14

Hi, There is a basic implementation of a header only Plugin library: https://github.com/apolukhin/Boost.Plugin Documentation with examples could be found here: http://apolukhin.github.io/Boost.Plugin/index.html Is there an interest in such library in Boost community? What features are missing in the library? Looking forward to hearing from you. Any feedback is more than welcomed. -- Best regards, Antony Polukhin

11 32

Review Wizard Status Report for August 2014
by Ron Garcia 02 Sep '14

02 Sep '14

============================================== Review Wizard Status Report for August 2014 ============================================== News ==== 1. Fiber Accepted Provisionally. January 2014. 2. Align Accepted. April 2014. 3. TypeIndex Accepted. May 2014. 4. Convert Accepted. June 2014. 5. Boost 1.56 Released -- New Libraries: Align, TypeIndex Open Issues =========== The following libraries have review managers, but have not yet been scheduled for review: * Range Extensions - added May 2012; review manager: Neil Groves. The following libraries have been accepted to Boost, but have not yet been integrated into Boost Git: * Contract - accepted September 2012; author: Lorenzo Caminiti. The following libraries have been accepted and submitted to Boost Git, but have not yet appeared in a release: * Convert - accepted June 2014; author: Vladimir Batov. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Fiber - accepted provisionally January 2014; author Oliver Kowalke. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot ubc dot ca" and "johnphillipsithica at gmail dot com" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Boost.Range Extensions * Nowide (M) * Array (M) * STL Extensions (M) * Countertree (M) * Process (M) * Asynchronous File I/O (M) * Application (M) * Edit Distance (M) * Mixin (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/cppmaven/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Array ----- :Author: Brian Smith :Review Manager: Needed :Download: https://github.com/BrianJSmith/Array :Description: The array class is a C++11 compatible implementation of static multidimensional arrays. STL Extensions -------------- :Author: Vadim Stadnik :Review Manager: Needed :Download: https://github.com/vstadnik/stl_ext_adv_review :Description: The proposed library [stl_ext_adv] offers augmented array based B+ trees and STL containers that support the interfaces of the C++03 sequences and associative containers. The library offers a number of extensions and performance improvements that are not available in C++03 and C++11 standard containers. Countertree ----------- :Author: Francisco Jose Tapia :Review Manager: Needed :Download: https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip :Description: This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators. COUNTERTREE This kind of trees have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators. With unordered information we have a vector with the same speed inserting and deleting in any position (O(log N)). With ordered information, we have the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract them. SUBALLOCATOR The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator replace to the allocator in the allocation of equal size elements. It provides speed, return the unused memory and decrease the memory used by the program and improve the cache performance due to the data locality improvement ( 30% of improvement of speed respect the std::allocator with GCC 4.7) Process ------- :Author: Boris Schaeling :Review Manager: Needed :Download: http://www.highscore.de/boost/process0.5/process.zip :Description: Boost.Process is a library to manage system processes. It can be used to: * create child processes * setup streams for child processes * communicate with child processes through streams (synchronously or asynchronously) * wait for processes to exit (synchronously or asynchronously) * terminate processes Asynchronous File I/O --------------------- :Author: Niall Douglas and Paul Kirth :Review Manager: Needed :Download: https://github.com/BoostGSoC/boost.afio/archive/boost-peer-review.tar.gz :Description: Boost.AFIO is a linear scalable, batch, chainable, asynchronous closure execution engine with an almost wait free implementation extending Boost.ASIO and Boost.Thread specialised as a portable asynchronous file i/o implementation library. Implementation of this first version has been kept as simple as possible (~ 1000 active LOC) at the cost of some performance, though with a good compiler you can expect 25-50% of the performance of using raw Boost.ASIO. Application ----------- :Author: Renato Tegon Forti :Review Manager: Needed :Download: https://github.com/retf/Boost.Application :Documentation: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html :Description: Application provides an application environment, or start point to any people that want a basic infrastructure to build an system application on Windows or Unix Variants (e.g. Linux, MacOS). Application uses behaviours modeled using 'aspects' concept proposed by 'Vicente J. Botet Escriba', that allow easy extension and customization of library components. The application modes uses these components internally to achieve the user desirable behaviours. Application provide many useful ready-to-use features, e.g: * Run application as Windows Service; * Run application as UNIX/POSIX Daemon; * Plugin extension system; * Process(executable) Single instance Instantiation support; * Application SIGNAL/Callbacks customization; * Windows Service Setup feature; * And many others. Edit Distance ------------- :Author: Erik Erlandson :Review Manager: Needed :Download: https://github.com/erikerlandson/algorithm/tree/edit_distance/sequence :Description: The edit distance is the length of the shortest (or least-cost) edit script from one sequence to another, where an edit script is defined as a sequence of insertion, deletion and (optionally) substitution operations. The function implementing the edit distance is named edit_distance. This function will return the edit distance between two sequences, where sequences may be any valid range object supporting forward iteration. The edit_distance function will also, if requested, return the edit script. Mixin ----- :Author: Borislav Stanimirov :Download: https://github.com/iboB/boost.mixin :Documentation: http://ibob.github.io/boost.mixin/ :Review Manager: Needed :Description: Boost.Mixin is a library that allows the composition and modifications of polymorphic types at run time. Types and objects are constructed out of building blocks called mixins. The library uses the type boost::mixin::object as a placeholder, whose instances can be extended with existing classes (mixins), thus providing a particular instance with the functionality of all those types. Accessing the newly formed type's interface is made through messages: stand-alone functions generated by the library, which can be thought of as methods. This is given while also having full abstraction between the interface and the definition of types. An existing feature in another language similar to Boost.Mixin and also an inspiration for the library are the mixins in Ruby. The library also has similarities with the pattern entity-component-system. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

2 3

[quickbook] miss-generated headings?
by John Maddock 01 Sep '14

01 Sep '14

I have a problem with quickbook code that has [h6 ...] elements in it - these end up being larger in both html and pdf output than [h5 ] blocks which is not so good :-( From what I can tell, [h5 ] actually produces html <h6> and [h6 ] produces html <h5>. BTW I realise [h6 ] is a lot of nesting, but the current stylesheet make <h6> quite a bit larger than surrounding text, so <h7> seems to be not beyond the realms of possibility? Thanks, John.

3 2

[build] b2 headers don't work for sublibs
by Andrey Semashev 01 Sep '14

01 Sep '14

Hi, I'm trying to move some headers of Boost.MPL to a sublib Boost.MPL.Core. I've reorganized the repository as follows: libs mpl book core include boost <- here and below are core headers test index.html doc example include boost <- here and below are the rest headers meta preprocessed test .git .gitattributes README.md index.html sublibs The problem is when I run 'b2 headers' the command creates a symlink boost/mpl pointing to libs/mpl/include/boost/mpl, which leaves out all headers from libs/mpl/core/include/boost/mpl. How do I instruct Boost.Build to create links to the core headers?

6 12