October 2015 - Boost - lists.preview.boost.org

Policy for individual library versioning
by Louis Dionne 15 Oct '15

15 Oct '15

Hi, I wonder whether there is a policy for how to version individual Boost libraries. Should individual libraries follow their own versioning scheme, or should they stick to the Boost versioning scheme? For example, Hana is currently in v0.4 and following Semantic Versioning[1]. I am wondering whether I should change Hana's version to 1.60.0 when it will be released with Boost 1.60.0, and from then on follow that versioning scheme (and drop Semantic Versioning, which I'm OK with). Hence, I would bump to 1.61.0 when Boost 1.61.0 is released, and so on. The other option is to stick with my current versioning scheme and simply document the correspondence between Hana vA.B.C and Boost vX.Y.Z. Is there any agreed-upon way to handle this? Regards, Louis [1]: http://semver.org

3 4

1.60 closes for new libraries and breaking changes in a week
by Vladimir Prus 15 Oct '15

15 Oct '15

Folks, the deadline for new libraries and breaking changes for 1.60 is next Wednesday, Oct 21. Please get big changes in by that date. Thanks, Volodya

4 7

Re: [boost] [c++std-parallel-2020] Re: We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Peter Dimov 14 Oct '15

14 Oct '15

Lawrence Crowl wrote: > First, std::async and std::future have no flaws for what they were > designed to do. They were designed to provide relatively easy parallelism > for small core systems under the fork-join model. I thought that it was well established by now that std::async isn't very useful for fork-join (if at all.) First, it's required to execute each (asynchronous) task as-if in a new thread with respect to thread locals, which in practice means "in a new thread". Second, it has to allocate the future shared state. These two non-flaws kill its performance for fork-join parallelism. The first one is not related to its use of std::future, but the second one is. Given an interface of the form X x; async_result<R> r; std::async( r, [&]{ return x.f(); } ); with async_result being non-copyable and non-movable and ~async_result blocking on the async task, the task can store its result directly into r, without needing to allocate.

1 0

Re: [boost] [c++std-parallel-2020] Re: We need a coherent higher level parallelization story for C++ (was [thread] Is there a non-blocking future-destructor?)
by Peter Dimov 14 Oct '15

14 Oct '15

Lawrence Crowl wrote: > Third, extending the use of std::future beyond its design goals caused > problems. You would expect this of any system used beyond its goals. In > particular, using std::futures for anything other than std::async was a > step too far. This is absolutely backwards. Future was always intended to be used as a generic future value. Hence the name, and the existence of 'promise'. Extending it beyond these design goals in order to imbue it with a lifetime management function caused the problems.

1 0

Test Runner Crashing
by Tom Kent 12 Oct '15

12 Oct '15

Over the weekend I've seen my windows test runner completely crashed (and other OS applications crashed as well), it is preventing the runner from getting through a complete run. I don't really have any idea where it is happening, but I have seen some errors in wserialization throwing up application crashed window...could this be related? Here's the info from the window: Problem signature: Problem Event Name: APPCRASH Application Name: test_non_intrusive_text_warchive.exe Application Version: 0.0.0.0 Application Timestamp: 561b13c0 Fault Module Name: MSVCP120D.dll Fault Module Version: 12.0.21005.1 Fault Module Timestamp: 524f8411 Exception Code: c0000005 Exception Offset: 000000000007c170 OS Version: 6.3.9600.2.0.0.272.7 Locale ID: 1033 Additional Information 1: 4de6 Additional Information 2: 4de60485dd55f55c5bf1ba0ca18762f0 Additional Information 3: 57a7 Additional Information 4: 57a7ea5113dd7a4cdeb1d88e51b65649 Read our privacy statement online: http://go.microsoft.com/fwlink/?linkid=280262 If the online privacy statement is not available, please read our privacy statement offline: C:\Windows\system32\en-US\erofflps.txt Here's the Visual Studio call stack: msvcp120d.dll!00007fff81a4c170() [Frames below may be incorrect and/or missing, no symbols loaded for msvcp120d.dll] msvcp120d.dll!00007fff819d88d2() msvcp120d.dll!00007fff819d9918() msvcp120d.dll!00007fff819e1511() > test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::_Endwrite() Line 643 + 0xcf bytes C++ test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::close() Line 341 + 0xa bytes C++ test_non_intrusive_text_warchive.exe!std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::~basic_filebuf<wchar_t,std::char_traits<wchar_t> >() Line 156 C++ test_non_intrusive_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::~basic_ofstream<wchar_t,std::char_traits<wchar_t> >() Line 1061 + 0x13 bytes C++ test_non_intrusive_text_warchive.exe!std::basic_ofstream<wchar_t,std::char_traits<wchar_t> >::`vbase destructor'() + 0x1c bytes C++ test_non_intrusive_text_warchive.exe!save(const char * testfile) Line 143 + 0x1b bytes C++ test_non_intrusive_text_warchive.exe!test_main(int __formal, int __formal) Line 169 C++ test_non_intrusive_text_warchive.exe!main(int argc, char * * argv) Line 203 + 0xe bytes C++ test_non_intrusive_text_warchive.exe!__tmainCRTStartup() Line 626 + 0x19 bytes C test_non_intrusive_text_warchive.exe!mainCRTStartup() Line 466 C kernel32.dll!00007fff8f7013d2() ntdll.dll!00007fff91fc5454() Any ideas? Could it be possible that too many application crashes could be taking out the test runner (and other OS applications) completely? Thanks, Tom

1 0

[Hana] Integration with the regression Matrix
by Louis Dionne 12 Oct '15

12 Oct '15

Hi, With the goal of shipping Hana with the next release of Boost, I am currently trying to satisfy the requirement that Hana's testing results show up in the Boost regression matrix. One way to achieve this would be to have Travis CI upload the results on each push to master. To do so, I would need to somehow create an XML file compatible with what the regression matrix expects. That brings up a few questions: (1) Is there a way to upload the result of CMake tests to the Boost regression matrix? I suspect something like that might have already been done as part of the (unfortunately defunct) CMake effort? (2) If not, would it be difficult to implement? Any input on how to best integrate Hana's testing results with the rest of Boost's regression testing will be greatly appreciated. Also, before someone suggests using Boost.Build: I have been looking at the possibility of maintaining a separate Jamfile. However, the need to maintain two separate build systems is annoying, so I'd like to avoid it if possible. I also think that Travis-based testing could provide a better coverage for Hana than the voluntary testers given the need for cutting edge compilers, but I could be wrong. Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Hana-Integration-with-the-regression-Mat… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 9

[thread] Is there a non-blocking future-destructor?
by Mikael Olenfalk 11 Oct '15

11 Oct '15

Hi, I have stumbled on a minor inconvenience when it comes to using boost::future. Below is a small example which first wraps an asio io_service as an Executor (see even further below) and then uses boost::async() to launch a simple task on the executor and tries to queue up a continuation using future::then(Ex, F): 1. the destructor of async_result does not block which is nice 2. the destructor of continuation_result does block which is a bit of an annoyance as this future I do not care about at all Is there a way to make the destructor not block? /M int main(int argc, char* argv[]) { boost::asio::io_service io_service; asio_executor executor{ io_service }; auto async_result = boost::async(executor, []() { return 42; }); // hangs: // async_result.then(executor, &g); // does not hang: auto continuation_result = async_result.then(executor, [](boost::future<int> r) { cout << r.get() << endl; }); cout << "start io_service" << endl; io_service.run(); cout << "stop io_service" << endl; return 0; } class asio_executor : public boost::executors::executor { public: asio_executor(boost::asio::io_service &ios) : _ios(ios) {} void close() override { _ios.stop(); } bool closed() override { return _ios.stopped(); } void submit(work&& w) override { // for some reason _ios.post(w); causes endless // recursion and eventually a crash _ios.post(std::move(w)); } bool try_executing_one() override { return _ios.run_one() > 0; } private: boost::asio::io_service &_ios; };

2 2

Boost.Fiber mini-review report
by Nat Goodspeed 10 Oct '15

10 Oct '15

The mini-review of Boost.Fiber by Oliver Kowalke ran from Friday September 4th through Sunday September 13th. There was lively discussion, but only two actual reviews: Agustín K-ballo Bergé: not yet (list of issues below) Niall Douglas: yes, plus suggestions (below)[0] In addition I received two "review withheld" notes: Vicente J. Botet Escriba wanted me to address the previous review point by point. That seems like a reasonable request, and I apologize, but I too have time pressures. Giovanni Piero Deretta made suggestions (synopsized below) with the statement that he will make a recommendation when he sees the library author's progress along those lines. While in theory these results might seem like a hung jury, the very paucity of formal reviews supports a cautious approach. The verdict is: not yet, with specific points as noted below. No reviewer explicitly designated specific points as being essential. (Niall Douglas explicitly designated his suggestions as post-adoption enhancements.) I have made an attempt to rank the recommendations received in descending order of importance to the community. My criteria are: Robustness: does lack of this request pose significant risk to a consuming program? API stability: could this request be considered an implementation detail, or would the change break early adopters? Demand: how many people requested the same thing? If you feel that I have misrepresented the importance of one of your points (or omitted something entirely), please respond. Ultimately, of course, the importance of any given point to the community at large will be reflected in the next mini-review. ----------------------------------------------------------------- Requests: Cross-thread fiber migration: Evidently the community strongly desires the ability to transfer a suspended fiber from one thread to another.[1] Of course there must be controls. Migration might be explicit; but if implicit, there must be a way to designate which fibers may and may not be migrated. An RAII class that temporarily disables migration would also be desirable -- for instance, to guarantee TLS consistency for some specific period. Cross-thread migration support implies a requirement to document the thread safety requirements of the customization API. Standard required timing specifications: meet (30.2.4 Timing specifications [thread.req.timing]). Adapt one or more existing test suites for thread facilities to validate the correctness of the Fiber library's synchronization constructs: e.g. from libc++, libstdc++, Boost.Thread, HPX. std::chrono support: ensure that wait_until() can accept any supported time_point specialization. (The library author asserts that this has already been fixed on the 'develop' branch.) C++11 compatibility: Agustín K-ballo Bergé volunteered to help with this point post-adoption. Paul Fultz offered fit::capture to emulate C++14 move capture. Document that this_fiber::yield() (et al.) are valid from main(), or in general from a thread function, as well as from explicitly-launched fibers. Make shared_state lock requirements explicit: for example, make mark_ready_and_notify_() accept a std::unique_lock<>& (or &&) to force its caller to provide one. Avoid holding mutex during condition_variable::notify_*() calls. (The library author asserts that this has already been fixed on the 'develop' branch.) packaged_task must not decay-copy its task arguments. Align fibers::async() signature, result description and invoke_helper implementation with std::async(). Avoid returning std::move(...). Wait list implementation: try an intrusive linked list of fiber_context objects. Avoid sleeping thread when no fibers are ready -- block on external event. Better handling of waiting tasks (decentralized wait queues?). Optimization to resume awakened fiber on the thread that awakens it. Template redundancy: eliminate duplication between specializations for T, T& and void. The future, shared_future, shared_state, promise and task_object templates were specifically cited. Leverage predicate-based condition::wait() overload internally. Nested schedulers: make schedulers be schedulable entities themselves. Improve robustness of `promise' handling in Asynchronous Callbacks documentation. Avoid overconfident remarks about it. Fix Note overstating the requirements on condition_variable::wait(). The discussion also surfaced the desirability of Grand Unified Future Theory, but it was generally agreed that this is out of scope. Put differently, it would be unreasonable to put the onus on Fiber to solve that very broad cross-library problem. Many thanks to all participants, and thanks especially to Oliver Kowalke for all his work on this library! Nat Goodspeed Boost.Fiber Review Manager ________________________________ [0] Niall Douglas snuck his review recommendation into the following mail message: http://lists.boost.org/Archives/boost/2015/09/225228.php (second to final paragraph). His suggestions were in private mail. [1] Giovanni Deretta suggests that it might be possible to allocate -- without actually running -- an actual kernel thread per fiber, simply to give each fiber its own TLS area.

2 1

Boost Library Testing - a modest proposal - was boost.test regression or behavior change (was Re: Boost.lockfree)
by Robert Ramey 10 Oct '15

10 Oct '15

I believe this whole thread started from the changes in Boost.Test such that it can no longer support testing of C++03 compatible libraries. This is totally unrelated to the testing of Boost libraries. Here is what I would like to see: a) local testing by library developers. Of course library developers need this in order to develop and maintain libraries. Currently we have this and has worked quite well for many years. Making Boost.Test require C++11+ throws a monkey wrench into things for the libraries which use it. But that's only temporary. Libraries whose developers feel they need to maintain compatibility with C++98 can move to lightweight test with relatively little effort. Developers who are concerned that the develop branch is a "soup" can easily isolate themselves from this by testing against the master branch of all the other libraries. The Boost modularization system with git has made this very simple and practicle (thank you Beman!). So - not a problem. b) Testing on other platforms. We have a system which has worked pretty well for many years. Still it has some features that I'm not crazy about. i) it doesn't scale well - as boost gets bigger the testing load gets bigger. ii) it tests the develop branch of each library against the develop branch of all the other libraries - hence we have a testing "soup" where a test might show failure but this failure might not be related to the library under test but some other library. It diminishes the utility of the test results in tracking down problems. iii) it relies on volunteer testers to select compilers/platforms to test under. So it's not exhaustive and the selection might not reflect that which people are actually using. I would like to see us encourage our users to test the libaries that they use. This system would work in the following way. a) A user downloads/builds boost. b) he decides he's going to use library X, and Y c) he runs a tool which tells him which libraries he has to test. This would be the result of a dependency analysis. We have tools which do similar dependency analysis but they would have to be slightly enhanced to distinguish between testing, deployment, etc. I don't think this would be a huge undertaking given the work that has already been done. d) he runs the local testing setup on those libraries and their dependents. e) he uploads the test results to a dashboard similar if not identical to the current one. f) we would discourage uses from just using the boost libraries without runnig they're own tests. We would do this by exhortation and by refusing to support users who have been unwilling to run and post local tests. This would give us the following: a) a scalable testing setup which could handle a Boost containing any number of libraries. b) All combinations of libraries/platforms/compilers actually being used would be those being tested and vice versa. We would have complete and efficient test coverage. c) We would have statistics on libraries being used. Something we are sorely lacking now. d) We would be encouraging better software development practices. Sometime ago someone posted that he had a problem but couldn't run the tests because "management" wouldn't allocate the time - and this was a critical human life safety app. He escaped before I could weedle out of him which company he worked. And best of all - We're almost there !!!! we'd only need to: a) enhance slightly the dependency tools we've crafted but aren't actually using. b) develop a tool to post the local results to a common dashboard c) enhance the current dashboard to accept these results. Robert Ramey

3 3

[nowide] Library Updates and Boost's broken UTF-8 codecvt facet
by Artyom Beilis 09 Oct '15

09 Oct '15

Some updated regarding boost.nowide 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream3. Added some C++11 interfaces to boost::nowide::fstream4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… And another important update is that I implemented proper utf8 to utf-16/utf-32 codecvt facet https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/ut… It implemented as template version working with wchar_t, char16_t and char32_t. Now I explain. There is widely used utf8 codecvt facet in various parts of code: https://github.com/boostorg/detail/blob/master/include/boost/detail/utf8_co… https://github.com/boostorg/detail/blob/master/include/boost/detail/utf8_co… However it is buggy and actually broken for 3 reasons: 1. It supports UCS-2 instead of UTF-16 - i.e it does not code properly Unicode characters outside BMP i.e. code points with values abouve 0xFFFF2. It allows invalid code points in UTF-32/UCS-4 i.e. above 10FFFF or that are reserved for surrogate pairs of UTF-163. And actually allows UTF-8 sequences longer than 4 (which is wrong) As a result, for example you can't use boost::filesystem::path with characters like "𝒞" U+1D49E or may actually create wrong encodings trying to read/write filesystem objects. Independently of Boost.Nowide I would like to propose replacement of boost/detail/utf8_codecvt_facet by one thatactually takes in account proper Unicode handling. Artyom Beilis--------------CppCMS - C++ Web Framework: http://cppcms.com/CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

7 47

[Build] Test file name conflicts
by Louis Dionne 09 Oct '15

09 Oct '15

Hi, While trying to create Jamfiles for Boost.Hana's unit tests, the following situation came up. I have two unit tests in files foo/main.cpp bar/main.cpp Then, my Jamfile.v2 contains the following: import testing ; test-suite xxx : [ run foo/main.cpp ] [ run bar/main.cpp ] ; When I run `b2`, I get the following: error: No best alternative for ./main next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched error: No best alternative for ./main next alternative: required properties: (empty) matched next alternative: required properties: (empty) matched I think the problem is that Boost.Build tries to create two executables named `main` in the same directory, which obviously causes a name conflict. Is there any way to avoid this, besides renaming the test files? Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Build-Test-file-name-conflicts-tp4680806… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Boost.lockfree
by Aparna Kumta 09 Oct '15

09 Oct '15

All tests for lockfree in both master and develop branch seem to fail. Error message is "../boost/system/config.hpp", line 34: Error: #error Must not define both BOOST_SYSTEM_DYN_LINK and BOOST_SYSTEM_STATIC_LINK. See develop branch: http://www.boost.org/development/tests/develop/developer/lockfree.html See master branch: http://www.boost.org/development/tests/master/developer/lockfree.html I looked at lockfree/test/Jamfile.v2 but am not sure what change needs to be made. Any suggestions? Thanks, Aparna

17 51

[Test] breaking changes in test invocation
by Jürgen Hunold 09 Oct '15

09 Oct '15

Hi, it seems that commit c0d2d29284389a1e7f924583ff6bd59128b9436b Author: Gennadiy Rozental <rogeeff(a)gmail.com> Date: Thu Oct 1 03:38:44 2015 -0400 -- is required before extra test module arguments has at least broken my Boost.Build driven tests, as I now get: Usage: my_test-clang38 [Boost.Test argument]... -- [custom test module argument]... For detailed help on Boost.Test parameters use: my_test-clang38 --help or my_test-clang38 --help=<parameter name> for every test which has extra command line arguments. I strongly suspect this breaks some libraries in Boost itself which e.g. need to read some input files. Right now I'm lost at how to fix this in Boost.Build's testing.jam as it seems we somehow have to specify different arg sets. And how to get "--" into the commandline at all. And in the light of the ongoing c++11/03 discussion it would have been nice to issue a warning before commiting breaking and/or behavioural changes. Any ideas? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 6

[Date_time] Adding Input Format Flag Parsers
by Yucheng Low 08 Oct '15

08 Oct '15

Hi, Boost date_time is missing a bunch of format flag parsers on input (%I,%l, %P, %p). Here is a proposed patch to add these format flags. Thanks, Yucheng

1 0

[regression] new runner missing in master results
by Ion Gaztañaga 08 Oct '15

08 Oct '15

Hi, Since MSVC-7.1 is (in theory) supported by Boost and we had no regressions on that platform, I've set up an old computer to do the job. I've executed regression tests several times and results appear in develop branch's result page but they are always missing in master branch. Logs indicate that executions and uploading were correct. Eg.: Runner "igaztanaga" present in develop: http://www.boost.org/development/tests/develop/developer/move.html Runner "igaztanaga" missing in develop: http://www.boost.org/development/tests/master/developer/move.html Any hint on what could be the problem? Ion

3 6

Boost.test failures in develop
by Aparna Kumta 08 Oct '15

08 Oct '15

Compiling with Oracle Solaris Studio on sparc-S2 platform with -library=stlport4, I see the following failure in the develop branch: "CC" -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_TEST_DYN_LINK=1 -DBOOST_TIMER_DYN_LINK=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/b_dev/results/boost/bin.v2/libs/test/build/sun/release/stdlib-sun-stlport/threading-multi/unit_test_parameters.o" "../libs/test/src/unit_test_parameters.cpp" "../boost/test/utils/runtime/errors.hpp", line 75: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 86: Error: Templates can only declare classes or functions. "../boost/test/utils/runtime/errors.hpp", line 124: Error: ")" expected instead of "&&". "../boost/test/utils/runtime/errors.hpp", line 133: Error: ")" expected instead of "&&". "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 69: Error: Unexpected ":" found. "../boost/test/utils/named_params.hpp", line 205: Error: Unexpected type name "Rest" encountered. "../boost/test/utils/named_params.hpp", line 205: Error: operator, is not defined. "../boost/test/utils/named_params.hpp", line 205: Error: "," expected instead of ";". ... Compilation aborted, too many Error messages. It seems that the code contains rvalue reference and hence the compiler is not able to build it in C++03 mode. This seems to be a recent change preventing building of libboost_unit_test_framework.a and hence causing several tests to fail. Thanks, Aparna

12 33

git reset and force push
by Raffi Enficiaud 08 Oct '15

08 Oct '15

Hi all, Is there any policy wrt. reseting a branch master/develop and force pushing? The side question is to know if the boost git tools (the bot for submodules) can cope with those operations. Thanks, Raffi

9 38

[serialization] static_warning.hpp seems behind boost/config
by Alain Miniussi 07 Oct '15

07 Oct '15

Hi, It seems that BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE has been replaced by BOOST_ATTRIBUTE_UNUSED in boost config. But static_warning.hpp is still using the old macro on master (while it is fixed on develop). On master: #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE; On develop: #define BOOST_SERIALIZATION_BSW(B, L) \ typedef boost::serialization::BOOST_SERIALIZATION_SS< \ sizeof( boost::serialization::static_warning_test< B, L > ) \ > BOOST_JOIN(STATIC_WARNING_LINE, L) BOOST_ATTRIBUTE_UNUSED; Could someone move the fix from develop to master to keep in synch with boost/config ? It is preventing some tests to pass in mpi. Thanks -- --- Alain

2 2

Boost.Filesystem for Universal Windows (windows-api=store)
by Mikael Olenfalk 06 Oct '15

06 Oct '15

Hi, I made a first attempt at getting Boost.Filesystem to run on the Universal Windows Platform (Windows 10). I intend to do more testing of it before it is ready to be merged but I would very much appreciate a quick and dirty review already. If somebody could take a look I would be a very happy guy. https://github.com/boostorg/filesystem/pull/18 I am working on some more libraries in the hopes that I can finish off most libs in the next couple of week, but I cannot promise anything. To compile for windows store, just add "windows-api=store" to your b2 invocation. Regards, /M

3 11

Request for review: Boost.Fit
by paul Fultz 06 Oct '15

06 Oct '15

Hi All, Boost.Fit is a header-only function utility library for C++11. It supports both gcc, clang and visual studio. More info can be found here: https://github.com/pfultz2/Fit I would like to take this time to ask for a review. Vicente Botet has mentioned he could be a review manager. So I would like to move forward in scheduling a formal review. I plan to boostify the library for the formal review. In addition, I would like to ask for an informal review at this time. If anyone has some feedback or questions, that would be greatly appreciated. Thanks, Paul

6 10

Boost.GSL?
by David Sankel 05 Oct '15

05 Oct '15

As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines. I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change. What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library? -- David Sankel [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [2] https://github.com/Microsoft/GSL

9 16

Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
by Brian Wood 04 Oct '15

04 Oct '15

Bjorn Reese writes >On 10/04/2015 12:18 PM, Gennadiy Rozental wrote: > >> Sooner rather than later we should have this discussion and setup timeline. >> IMO it had very little sense to continue to maintain c++03 workarounds. >> Boost code should be an example how modern c++ libraries should look like. >> And c++03 compatibility is directly in a way of this goal. > > You appear to have missed the many discussions on this topic. > > While Boost started out to design cutting-edge libraries, it has been > caught by its own success. Today there is a large user-base that still > uses C++03, and that are unlikely to upgrade in the foreseeable future. > > Therefore, the current consensus is that existing libraries should not > increase their standards requirements. New libraries are free to decide > their standards requirements (although it will probably be questioned > during a formal review.) > Support for that is dwindling as more projects adopt 2011 or newer versions of C++. I understand Gennadiy and Raffi's desire to discuss this issue again. C++ 2011 is required to use my software. That decision was also based on limited resources and the belief that C++ 2011 had some helpful things for on line code generation. If I had more resources, I could support C++ 2003, but at this point I'm happy to not have to support that. As time goes on, more people are using C++ 2011 or newer. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0

Boost perf tests?
by Stephan T. Lavavej 03 Oct '15

03 Oct '15

Hi Boost devs, Does Boost have any runtime perf tests? We (MSVC) are looking for something that uses modern C++, which would reveal areas where our optimizer and libraries could be improved. I looked around briefly, but didn't find anything. Thanks, STL

6 6

[optional] Specializing optional to save space
by David Stone 03 Oct '15

03 Oct '15

Andrzej posted another thread about creating a new compact_optional class. The goal of this class is to make it easy to create a new optional type with a special sentinel value. This allows easy customization per instance of an optional value. This post is about the opposite approach: making it easier to specialize optional to provide special behavior for all instances of a given optional type. When I bring this up, people often compare it to the vector<bool> specialization, but this is a completely different issue. The problem of vector<bool> is that it does not actually store a bool anywhere, so it cannot return a reference to one. This would still store a T somewhere. For the rest of the discussion, I will be assuming a typical standard library implementation on a 64-bit system. Whenever I talk about specific sizes of objects, mentally insert "on most common systems". The principles apply generally. Consider the case of optional<std::string>. Using the naive implementation, this object is 8 bytes larger than std::string, due to alignment requirements. However, there are certain representations of std::string that are not actually possible. For instance, for common implementations of std::string you cannot have std::string::size() == std::numeric_limits<std::string::size_type>::max() *. We can take advantage of this if our std::string implementation stores the capacity as an integer value, rather than a pointer to the end of the storage. Therefore, we could have implementations that look something like this: class string { friend optional<string>; }; template<> class optional<std::string> { optional(none_t) { // Use friendship to just set capacity to sentinel value } explicit operator bool() const { return m_data.capacity() == std::numeric_limits<std::string::size_type>::max(); } }; optional<std::string> still stores std::string in it, so operator*() works just fine. The initialized check is still just comparing a field against a compile-time constant. This makes this purely a space optimization that cannot be detected by the user, unless they use sizeof(optional<std::string>). I believe all of this is possible today with the current specification of boost::optional (and would definitely be allowed for the proposed std::experimental::optional). However, this requires the creator of each specialization to implement the full optional interface. What's more, it is especially tricky to specialize optional for a class template when you only want to specialize on certain specializations of the class template. My use case for this is my bounded::integer library. This library lets you specify the bounds of your integer as template parameters. If your bounded::integer has a narrower range than its underlying integer, you can take advantage of this to make a more space-efficient optional. If, however, the bounded::integer min and max are equal to that of the underlying type, there is no extra space and we want the default optional implementation. With the current specialization approach, it is the responsibility of the specializer to reimplement all of optional. A better approach to easily support this space optimization is as follows: optional contains an instance of optional_storage<value_type>. optional_storage has a much narrower interface: * optional_storage() leaves it uninitialized * optional_storage(in_place_t, T && ...) constructs the value directly with the variadic arguments * emplace(T && ...) constructs an object when there may be one in existence already * reset() destroys the contained object and sets the storage to uninitialized * is_initialized() says whether the contained object is initialized. This could be replaced with explicit operator bool(); I have no preference. * value() returns a reference to the value We need both the constructor and the emplace function to allow literal optional types. This is because for the general case, emplace calls placement new, which is not allowed in a constexpr function. This solves the problem of specializers having to implement the entire interface of optional just to change how the uninitialized state is stored. However, it still does not solve the problem I mentioned earlier about allowing easy use of the default storage policy for some specializations of your own class template. To solve that, we need one more class: default_optional_storage. default_optional_storage<T> is a literal type if T is a literal type (in practice, std::is_trivially_destructible<T>::value is all you really need to test). It implements the same interface as optional_storage<T>. The default implementation of optional_storage<T> is template<typename T> struct optional_storage : default_optional_storage<T> { private: using base = default_optional_storage<T>; public: using base::base; }; This means that the optional library would have at least three classes in its public interface: * optional * optional_storage * default_optional_storage To see a working example of this (including a specialization for bounded::integer), see https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… https://bitbucket.org/davidstone/bounded_integer/src/2defec41add2079ba023c2… * The reason is that std::string::size_type is a typedef for std::size_t, which is equivalent in range to std::uint64_t. However, std::iterator_traits<std::string::iterator>::difference_type is std::ptrdiff_t, which is equivalent in range to std::int64_t. This means that for the largest std::string, std::distance(begin(), end()) cannot be more than std::numeric_limits<std::ptrdiff_t>::max(), which is less than std::numeric_limits<std::size_t>::max().

6 15

[type_traits] common_type errors with Oracle compiler
by Andrey Semashev 03 Oct '15

03 Oct '15

Hi, Both oracle-intel-S2-next-cpp11 and oracle-sparc-S2-next-stlport4 testers fail to compile common_type as it is being used in Boost.Chrono. This in turn affects compilation of Boost.Thread and multiple other library tests. The error can be seen here: http://www.boost.org/development/tests/develop/developer/output/oracle-inte… Just in case if the test results go down, I'm copying the error inline below. Could it be fixed? "CC" -std=c++11 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -D__typeof__=__typeof__ -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_intel-S2_cpp11/results/boost/bin.v2/libs/atomic/test/atomicity.test/sun-next_cpp11/release/threading-multi/atomicity.o" "../libs/atomic/test/atomicity.cpp" "../boost/chrono/duration.hpp", line 405: Error: type is not a member of boost::common_type<long long, long long>. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: A declaration does not specify a tag or an identifier. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: Use ";" to terminate declarations. "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/chrono/duration.hpp", line 406: Error: "}" expected instead of ">". "../boost/thread/pthread/timespec.hpp", line 52: Where: While specializing "boost::common_type<boost::chrono::duration<long long, boost::ratio<1, 1000000000>>, boost::chrono::duration<long long, boost::ratio<1, 1>>>". "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from boost::chrono::operator-<Rep1, Period1, Rep2, Period2>(const duration<Rep1, Period1>&, const duration<Rep2, Period2>&). "../boost/thread/pthread/timespec.hpp", line 52: Where: Instantiated from non-template code. "../boost/thread/pthread/timespec.hpp", line 52: Error: The operation "const boost::chrono::duration<long long, boost::ratio<1, 1000000000>> - boost::chrono::duration<long long, boost::ratio<1, 1>>" is illegal. 5 Error(s) detected.

3 4

Compiler warnings after boost update
by Auer, Jens 03 Oct '15

03 Oct '15

Hi, we compile with high compiler warnings setting (-Wall, -Wpedantic), and treat compiler warnings as errors. Recently, I had to upgrade the boost library version from 1.53 to at least 1.55. Since there was no package available, I compiled it by hand from the source code. With 1.53, everything compiled fine, but with the newer version my builds now break because the boost library generates a lot of warnings, e.g. /cots/boost-1.55/include/boost/iterator/iterator_concepts.hpp: At global scope: /cots/boost-1.55/include/boost/mpl/assert.hpp:288:54: error: use of old-style cast [-Werror=old-style-cast] boost::mpl::assert_arg( (void (*) pred)0, 1 ) \ ^ /cots/boost-1.55/include/boost/mpl/assert.hpp:59:58: note: in definition of macro ‘BOOST_MPL_AUX_ASSERT_CONSTANT’ # define BOOST_MPL_AUX_ASSERT_CONSTANT(T, expr) enum { expr } /cots/boost-1.55/include/boost/range/algorithm/equal.hpp: In function ‘bool boost::range::equal(const SinglePassRange1&, const SinglePassRange2&, BinaryPredicate)’: /cots/boost-1.55/include/boost/concept/detail/general.hpp:71:20: error: typedef ‘boost_concept_check185’ locally defined but not used [-Werror=unused-local-typedefs] BOOST_PP_CAT(boost_concept_check,__LINE__) /cots/boost-1.55/include/boost/property_tree/xml_parser.hpp:52:59: required from ‘void boost::property_tree::xml_parser::read_xml(std::basic_istream<typename Ptree::key_type::value_type>&, Ptree&, int) [with Ptree = boost::property_tree::basic_ptree<std::basic_string<char>, std::basic_string<char> >; typename Ptree::key_type::value_type = char; typename Ptree::key_type::value_type = char]’ /home/auerj/MDAF/src/commons/src/crypto/KeyFileReader.cpp:43:34: required from here /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] if (first_attribute()) ^ /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1204:33: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] /cots/boost-1.55/include/boost/property_tree/detail/rapidxml.hpp:1211:45: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] These are just some examples, there are literally hundreds of warnings. It is enough to just include ptree.hpp, but other headers have the same issue. I am wondering why this came up after the update. Is it a configuration problem during the build of the boost libraries, or is it an issue in the boost libraries? I find it hard to believe that the code quality changed so much between the versions. What is the policy of the boost project concerning compiler warnings in installation headers? I would assume that the libraries should compile without warnings on supported compilers, either because there are no issues, or because warnings are disabled in the boost headers. Best wishes, Jens -- Jens Auer | CGI | Software-Engineer CGI (Germany) GmbH & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com<mailto:jens.auer@cgi.com> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

10 14

[build][regression] Problems when trying to run automated regression tests for MSVC-7.1
by Ion Gaztañaga 03 Oct '15

03 Oct '15

Hi, Since Boost 1.55 minimum requirements include Visual C++ 2003. Since currently there is no regression report for this compiler, I'm trying to follow the steps detailed here and try to fill the gap: http://www.boost.org/development/running_regression_tests.html All the source code is downloaded, my user-config.jam only contains "using msvc ;" but it seems that Boost.Build continues to be broken for MSVC-7.1: <output> notice: Loading user-config configuration file 'user-config.jam' from 'C:/Users/igaztanaga'. notice: [msvc-cfg] msvc-7.1 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe' for msvc, condition <toolset>msvc-7.1 C:/boost/develop/boost_bb/src/tools\msvc.jam:1072: in configure-really *** argument error * rule generate-setup-cmd ( version : command : parent : options * : cpu : global-setup : default-global-setup-options : default-setup ) * called with: ( 7.1 : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin : C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7 : <command>C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe : i386 : : x86 : vcvars32.bat ) * missing argument global-setup C:/boost/develop/boost_bb/src/tools\msvc.jam:798:see definition of rule 'generate-setup-cmd' being called C:/boost/develop/boost_bb/src/tools\msvc.jam:201: in configure C:/boost/develop/boost_bb/src/tools\msvc.jam:153: in msvc.init C:/boost/develop/boost_bb/src/build\toolset.jam:43: in using C:\Users\igaztanaga\user-config.jam:49: in modules.load c:/boost/develop/boost_bb/src\build-system.jam:249: in load-config c:/boost/develop/boost_bb/src\build-system.jam:389: in load-configuration-files c:/boost/develop/boost_bb/src\build-system.jam:524: in load C:\boost\develop\boost_bb\src/kernel\modules.jam:295: in import C:\boost\develop\boost_bb\src/kernel/bootstrap.jam:139: in boost-build C:\boost\develop\boost_regression\boost-build.jam:57: in module scope </output> I can't figure out what's wrong in msvc.jam. Comments on that file suggest that MSVC-7.1 should be supported although it seems that since MSVC-8.0 the configuration script architecture changed. I'd be glad if any Boost.Build expert could have a look at this issue. Many thanks, Ion PS: Full output for command... python run.py --runner=igaztanaga --toolsets=msvc-7.1 --tag=develop --incremental --libraries=move --have-source > output.txt ...attached.

2 4

compact_optional -- prompting interest
by Andrzej Krzemienski 02 Oct '15

02 Oct '15

Hi Everyone, I would like to inquire if there would be an interest in Boost in another library for storing optional objects, but working under different design goals. Compact optional T has (or can have) the same sizeof as T. It uses one indicated value of T to represent the "empty" (or "singular") value. You can declare it like this: compact_optional<evp_int<int, -1>> oi; This reads: we have an optional int, with type int inside, where -1 represents the empty value. It can never have a genuine (non-empty value -1). This can be used, for instance, to wrap the std::string::npos into: compact_optional<evp_int<string::size_type, string::npos>> With the same memory layout as std::string::size_type, but with the special syntax for managing the singular value. It is not meant to be an alternative to Boost.Optional: it targets a different application space. The (single-header) implementation is at: https://github.com/akrzemi1/compact_optional The documentation is at: https://github.com/akrzemi1/compact_optional/blob/master/documentation.md For the motivation and design rationale see this article: https://akrzemi1.wordpress.com/2015/07/15/efficient-optional-values/ Any feedback is welcome. Regards, &rzej

17 43

[build] Issue with -- argument
by Gennadiy Rozental 01 Oct '15

01 Oct '15

Hi, Due to the change in Boost.Test parameter handling I needed update Boost.Test Jamfile, since I was passing baseline pattern file names as arguments to the test module. Here is snippet from my Jamfile: return [ $(test-rule) $(source_files) ../build//$(usage-variant) $(extra-libs) : -- <============= Note: I added '--' : $(pattern_file) ... Unfortunately -- disappears for some reason from command line. I found that the following works: return [ $(test-rule) $(source_files) ../build//$(usage-variant) $(extra-libs) : -- "" <============= Note "" : $(pattern_file) ... Can we fix it so that "" is not required? Is there a different workaround? Gennadiy

1 0