September 2014 - Boost - lists.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