- Boost - lists.preview.boost.org

[Better Enums] Maps between enums and other types
by Anton Bachin 12 Jul '15

12 Jul '15

Hello, In past exchanges on this list, several people expressed a desire for bidirectional maps on enums. I've made a simple implementation [1] that relies on constexpr functions containing a switch. The switch forces case exhaustiveness checking. This method therefore requires C++14 to be truly useful. Usage is: ENUM(Channel, int, Red, Green, Blue) constexpr const char* describe(Channel channel) { switch(channel) { case Channel::Red: return "the red channel"; case Channel::Green: return "the green channel"; case Channel::Blue: return "the blue channel"; } } constexpr auto descriptions = better_enums::make_map(describe); int main() { std::cout << descriptions.from_enum(Channel::Red) << std::endl; std::cout << descriptions.to_enum("the green channel") << std::endl; } This prints the red channel Green In principle, make_map should enumerate the function by passing every possible value of Channel, and use the results to build up some lookup data structure. I am not doing that right now because I haven't found a compile-time data structure with fast enough generation to be practical. I suppose with reflective information, there are other ways to check for exhaustiveness besides using a switch. The implementation is currently inefficient (it uses a linear scan to do the reverse mapping). There is also no support for multimaps or partial maps. I could probably support the latter easily by having the function return an option type. I am not sure multimaps are a good idea at all. The only point of them would be to do a reverse mapping from multiple values to the same enum. Interested to hear any opinions. Anton [1] http://aantron.github.io/better-enums/tutorial/Maps.html

1 0

Another Problem (was RE: [type_traits] Another big update in develop)
by Fletcher, John P 11 Jul '15

11 Jul '15

A recent change on develop is breaking something in boost function: _In file included from ../../../boost/function/function_base.hpp:22:0, from ../../../boost/function/detail/prologue.hpp:17, from ../../../boost/function.hpp:24, from ../../../boost/thread/future.hpp:52, from ../../../libs/thread/src/pthread/thread.cpp:19: ../../../boost/type_traits/has_trivial_copy.hpp:47:47: error: template argument 1 is invalid This was not there yesterday. John Fletcher

3 6

Boost.Hana
by Glen Fernandes 11 Jul '15

11 Jul '15

Dear Ron, Louis, and Boost developers, The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support. I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library. Thank you again, Louis, for your work on Hana and for contributing it to Boost. I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful. I trust, but do not mandate before Hana is officially accepted into Boost, that: 1. All GitHub issues pertaining to implementation and documentation that were opened by Louis in response to review feedback (or by others, such as Vincente, that were approved by Louis) will be addressed eventually (as long as they remain relevant). I personally would ask for, but do not require for Hana's acceptance, that: 1. That Hana's non-reference documentation live outside of the source code. The presentation of Hana's documentation is great; it looks modern, is easy to browse. I am not a fan of the prose living inside hana.hpp though (API reference documentation is the only exception). 2. Louis to investigate further the possibility of a Hana core library if such can be achieved with zero overhead (instead of focusing that effort onto a separate library that provides only a subset of Hana's functionality). On the note of Hana's current support in existing C++ implementations: - While Hana is wholly only supported by clang at present, gcc is not far behind. Given the trend of language conformance, it is reasonable to expect Hana will be entirely supported in a future gcc release. - Hana targets the C++ standard (i.e. This isn't a case of targeting any compiler-vendor specific extensions) and any highly-contentious C++ language features within (e.g. This isn't something like a pre-C++11 library that uses 'export' that only builds with an EDG compiler). - The community now has expressed sufficient interest in both kinds of libraries being part of Boost: Highly portable libraries that target implementation-specific features, and maintain compatibility with even legacy compilers; standard conforming, modern, libraries that are free of the maintenance debt of ancient compiler support. - We need more libraries taking advantage of C++14 language features to drive vendor conformance. A standard may only be as potent as the C++ implementations that support support it, but when one (such as clang does) does, others will be more driven to follow suit when real (and highly desired) projects take advantage of it. My thanks to everyone that participated in Hana's review with a review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel, Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul, Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug reports. Best, Glen

7 9

[BestPracticeHandbook] Run this code online
by Krzysztof Jusiak 11 Jul '15

11 Jul '15

Hi, I've recently added a new functionality to proposed boost.di library documentation. After `try it online` the natural next step was to add `run this code` functionality like in http://en.cppreference.com/w/ or http://www.rust-lang.org/ programming language. Powered by Wandbox and CodeMirror approach, let you play with the particular example and switch between normal quick book programming listing mode and the editor/compiler mode. You can check it here: http://krzysztof-jusiak.github.io/di/cpp14/boost/libs/di/doc/html/di/exampl… Just click on `Run this code` button and you will be switched to the editor mode, where you would be able to edit the code and compile it online using the newest version of the library. Implementation details: https://github.com/krzysztof-jusiak/di/blob/cpp14/doc/js/run_this_code.js It's basically the same solution as `try it online`, just implemented in js instead. Additionally, it also takes the newest version of the library from github. Minimal html: <link rel="stylesheet" href="CodeMirror/lib/codemirror.css"> <link rel="stylesheet" href="CodeMirror/theme/zenburn.css"> <script src="CodeMirror/lib/codemirror.js"></script> <script src="CodeMirror/mode/clike/clike.js"></script> <script src="CodeMirror/addon/selection/active-line.js"></script> <script src="run_this_code.js"></script> <button class="TryItBtn" id="run_it_btn" onclick="show(' https://raw.githubusercontent.com/krzysztof-jusiak/di/cpp14/examples/hello_…)">Run this code!<\/button> <textarea style="display: none" id="code"></textarea> <textarea style="display: none" id="output"></textarea> <div id="code_listing"> //quick book programming listing here or anything else, which should be hidden when editor mode is enabled </div> Let me know, what do you think. Cheers, Kris

3 2

Using clang on Windows with mingw-64
by Edward Diener 11 Jul '15

11 Jul '15

This is just a heads up about testing with clang on Windows. The latest clang, when built from the latest source, is now capable on Windows of using the mingw-64/gcc RTL. Furthermore it is no longer necessary to have the mingw/mingw-64 implementation hardcoded or linked from c:\mingw. With the latest clang the executable will look for a mingw/mingw-64 implementation on the PATH, meaning that the if the implementation's 'bin' directory is on the PATH clang will find it and use its RTL. The ability of the latest clang to use mingw-64 means that clang can use the latest gcc-5.1 RTL on Windows. The mingw-64 implementation offers more up to date and better implementations of gcc than mingw. There is one "gotcha" I have found with this setup on Windows when using clang on Windows with gcc-4.9 on up. The gcc intrin.h implementation of mingw-64 for gcc-4.9 on up has a bug where if the gcc version is less than 4.9 a compiler error will occur. I have reported this to mingw-64 on their developer's mailing list but it has been ignored. Unfortunately clang still sets itself to gcc version 4.2.1. But a workaround solves the problem and that workaround is that when using clang you define '__MINGW_FORCE_SYS_INTRINS', which causes the bug in the mingw-64 intrin.h header file to not trigger. Previous versions of clang on Windows ( 3.4, 3.5, 3.6 ) of course still have the limitation of only working with mingw and needing the mingw implementation hardcoded at c:\mingw. But at least with the latest clang built from source this has changed as explained above. The Boost build clang toolset, which on Windows is really clang-linux, should continue to work with this latest change of clang.

2 2

[1.59] Boost 1.59 schedule?
by Joaquin M López Muñoz 09 Jul '15

09 Jul '15

Hi, The official release schedule at http://www.boost.org/development/index.html seems to indicate we're now really close to the first beta of Boost 1.59, yet I don't see much activity in the mailing list and, for instance, the release notes are almost empty now: https://github.com/boostorg/website/blob/master/feed/history/boost_1_59_0.q… Is this schedule still valid? Thank you, Joaquín M López Muñoz Telefónica

6 7

Problem cross-compiling boost.context for Raspberry Pi (2)
by Biddiscombe, John A. 09 Jul '15

09 Jul '15

Hello list, I am able to compile the full set of boost libraries on the Raspberry Pi, and I get all the libraries successfully built, including context and coroutine which I need. However, when I cross compile on an Ubuntu virtual machine setup for the job, all the libraries except context/coroutine are built. The problem seems to be that when cross compiling, the file "unsupported.cpp" is being pulled in (here is a verbose output showing flag I'm using) "/home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_CONTEXT_SOURCE -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_DLL=1 -DNDEBUG -I"." -c -o "bin.v2/libs/context/build/gcc-arm/release/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp" which emanates from the jamfile boost_1_58_0/libs/context/build/Jamfile.v2 where the following alias asm_context_sources : unsupported.cpp ; is in a section marked #COMBINED Now, when I build on the pi itself, this file is not being added to the build, so it seems to me that during the bootstrap phase on the pi, different flags are being used which trigger the correct behaviour of bjam my user-config.jam looks like this using gcc : : /home/biddisco/pi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ : <compile-flags>-D__arm__ -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard ; (NB. I added -D__arm__ to see if it helps, but it does not make a difference without it). I have no knowledge of how bjam / boost.build do their things, so I do not know what to try next. It seems that I need to bootstrap the build using the flags for the pi, but built for the host so that it can generate the correct makefiles and this looks like where the problem is arising. the build process seems good apart from this wrinkle The bootstrap command I'm using is ./bootstrap.sh --with-toolset=gcc and the build appears sensible when I use ./b2 cxxflags="-D__arm__ -std=c++11 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" --layout=versioned threading=multi link=shared variant=release -j8 Performing configuration checks - 32-bit : yes - arm : yes .... etc etc Can anyone see what I'm doing wrong? (Note : With another project which depends on libpthread, I had to copy libpthread from the pi to the host and force the linker to use the pthread lib from the pi and not the host one, does bjam do something internally which might require a trick like this? - note2 - the binaries generated via this process run without error) Many thanks JB -- John Biddiscombe, email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82

4 17

Json read...segment by segment
by vijay.singh＠edisphere.com 07 Jul '15

07 Jul '15

Hi, I am using below code to read load Json file in boost::property_tree::ptree object. Function read_json(.) read all file content at a time. I want to know is there any way to read file content segment by segment. Thanks and regards, Vijay int _tmai3n(int argc, _TCHAR* argv[]) { try { std::stringstream ss; std::ifstream file("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\Inputfiles\\AI98_Test_3.json", std::ios::binary); // Make sure we have something to read. if (!file.is_open()) { throw (std::exception("Could not open file.")); } // Copy contents "as efficiently as possible". ss << file.rdbuf(); boost::property_tree::ptree pt; boost::property_tree::read_json(ss, pt); boost::property_tree::write_json("D:\\EdisphereComp\\kit\\1003_Kit\\1003\\In putfiles\\AI98_Test_3_sprite.json", pt); } catch (boost::property_tree::json_parser_error e) { ; } //} return 0; }

4 7

Boost.Test v3 is in master
by Gennadiy Rozental 07 Jul '15

07 Jul '15

Hi, I've merged new Boost.Test into the master branch. We'll look for any regressions, but I do not expect big changes before release. Gennadiy

2 1

[test] Bug in Mingw support?
by John Maddock 07 Jul '15

07 Jul '15

The short program below passes with MSVC and GCC Linux, but fails with Mingw-x64 at runtime (the expected failures count gets ignored). This is with current develop. Any ideas? BTW the new decorator based approach does work OK, but is only supported on a tiny number of compilers as it seems to rely on the preprocessor lib using variadic macros, as opposed to Boost.Config marking them as available. Here's the program: #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> BOOST_AUTO_TEST_CASE_EXPECTED_FAILURES(test_main, 10000); BOOST_AUTO_TEST_CASE(test_main) { BOOST_ERROR("one"); BOOST_ERROR("two"); } Thanks, John.

3 7

Boost Graph maintenance
by Oodini 07 Jul '15

07 Jul '15

Hello, I've been working on BGL for several days, and I'll probably have to work on it for a long time. The documentation is not very clear (I suspect it is outdated on some points), and as it doesn't seem complete. Also, the official maintener, Jeremiah Willcock, hasn't commited since the end of 2013. I'd like to work on the documentation, in the first time on the organization and presentation. If I amend the text later, I will need a reviewer (my english is not good enough). What would be the process ? I havn't participated to any Boost library.

5 5

Boost.Experimental Re: [variant] Maintainer
by Gottlob Frege 07 Jul '15

07 Jul '15

On Sun, Jun 28, 2015 at 10:29 AM, Agustín K-ballo Bergé <kaballo86(a)hotmail.com> wrote: > On 6/28/2015 5:38 AM, Vicente J. Botet Escriba wrote: >> >> Le 27/06/15 21:32, Agustín K-ballo Bergé a écrit : >>> >>> On 6/27/2015 12:38 PM, Vicente J. Botet Escriba wrote: >>>> >>>> I would accept Eggs.Variant without even a review (or with a minimal >>>> review) as an experimental library as part of Boost.Variant after some >>>> minimal adaptation to fit in Boost of course. >>> >>> First of, as I have already said before, Eggs.Variant is an >>> experiment. As such it is highly unstable, and I reserve the right to >>> change things in any way I see fit, with no regards for backwards >>> compatibility, maintenance, or support. I have made these kinds of >>> changes in the past, and I have more planned for the near future. I >>> think it would be unwise to make it a part of Boost, even as an >>> experimental library, until the design has fully hatched ("Eggs", get >>> it?). >> >> Agustin, this is exactly the kind of constraints of an experimental >> library. When the design is fully hatched then it moves to non >> experimental. > > > I fail to see the point in including an experimental library that changes > its interface every month into Boost, which is released every 3 months or > so. By the time you get your hands in a release, the interface of the > library has already changed. And the library as such would only exist for a > single release. > > Who would benefit from Boost packaging old snapshots of experimental > libraries? > > Perhaps you'd wish to bring back the Sandbox > (http://www.boost.org/community/sandbox.html) which has been superseded by > standalone repositories since the move to Git. > I think we need *something* for experimental libraries. Even if it is just someone's own git repository stamped (but not endorsed) with the Boost "brand". Or a page in boost.org listing current experiments. Or... something. There are (at least) 2 needs that Boost tackles: 1. great libraries that solve problems for developers 2. great libraries that can turn into std:: libraries I think we are doing better on 1 than 2. I think 2 requires more experimentation (whereas 1 requires more stability). Yes I know 2 looks successful - just look at how much of boost is in C++11. But when each Boost library is brought to the committee, we have 2 choices: - make design changes before going into std - take as is Making design choices in a committee (and without experimenting) is not always a good idea. We are, in theory at least, suppose to standardize existing behaviour. Taking as is means we are accepting whatever was good enough to pass Boost review as *best*. Boost review is a high bar, but the std:: should be higher. It is common for the committee to hear/say "boost users have been using it this way for years". That is usually a good strong argument - we want/need implementation and usage experience. But saying "this works" doesn't mean something else could work better. Implementation/usage experience is most accurate when it says "this does NOT work", because then you have ruled out an option. When you say "this works", it doesn't rule out options that might work _better_. We are increasingly going with option 3: - put into std::experimental which delays the desired outcome of getting great libraries into the standard. I'd like some kind of experimental area that would help find the best possible libraries. What I'd _really_ like is more experimentation in _current_ Boost libraries, breaking users left and right - I'd rather break boost users than std:: users. (We have and will make breaking changes in the standard library). But I understand that current users wouldn't be too happy about breaking changes _just for experimentation's sake_. And if we lost the boost user base, boost would no longer be helpful to the standard at all. (As a reasonable example of not being afraid of breaking changes: Sean Parent's Adobe Standard Library would boldly break whenever he thought something could be made better. It didn't break just for experimenting, but he wasn't afraid to make breaking changes for the better.)

6 11

[predef] Using predef-check on 'develop' problem
by Edward Diener 06 Jul '15

06 Jul '15

In a jam file I have for a run test a predef-check which looks like: run test_variadic_macro.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ; When running on QNX with the gcc version greater than 4.3 I would expect that -std=c++0x would not be added as a C++ compile parameter to the run. Yet it is being added to the run. Another test confirms that BOOST_OS_QNX is indeed being set to a non-zero value. Is there a bug in predef-check ? Am I using it incorrectly ?

4 45

Testing InputIterator on the interface
by Benedek Thaler 05 Jul '15

05 Jul '15

Hi, I'd like to verify my methods accepting an input range (two iterators modelling InputIterator) do a single pass over the range at most. I'd like to have an iterator adaptor, which erases the visited element upon incrementing. So far, I found these: 1) https://github.com/boostorg/test/blob/master/include/boost/test/utils/itera… I couldn't find its documentation, and does not seem to what I want. 2) https://github.com/boostorg/container/blob/master/test/input_from_forward_i… Despite the name, still not something I want. I'm developing a Boost.Container class [0], so using container/test would be okay. Is there such a thing ready somewhere or shall I roll my own? Thanks, Benedek [0]: https://github.com/erenon/container/blob/devector/include/boost/container/d…

2 3

Re: [boost] [Boost-users] Boost.DLL formal review is ongoing
by Klaim - Joël Lamotte 04 Jul '15

04 Jul '15

On 4 July 2015 at 11:38, Antony Polukhin <antoshkka(a)gmail.com> wrote: > 2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: >> >> >> On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >>> >>> - What's your evaluation of >>> - Design >>> >> >> I consider the solutions provided to solve each usual issue with plugin >> systems to be simple >> and clear, easy to use (as long as you understand what loading plugins >> imply). >> >> Until I check in some complex cases, I think the design is very good. >> The symbol name magic might be tricky to understand sometime but it's an >> issue which is a side effect of providing >> a simple tool to manage symbole names, so it's still good. >> >> One thing I was wondering: would it be possible to provide a way to load >> shared libraries from >> raw memory? Or does the OS APIs all requires that the library have to be >> on a file sytem? >> > > Unfortunately, there's no portable way to load libraries from raw memory. > However you can always mount a filesystem that directly maps to memory (for > example Tmpfs on Linux) and store your data in there. This may look like a > big performance overhead, but actually loading a shared library takes much > time so you won't probably notice the overhead of additional create_file + > memcpy. > It's ok, the solution to write a shared library in the the filesystem before loading it is what Ihave been doing so far and it works well. I was just wondering if it was possible with memory. :) If the plugin is in an archive file, I have to extract it in a temporary directory before loading it, which is what I would like to avoid, but it seems unavoidable. > > If you're planing this feature to write interpreters\JIT compillers and > you just need a place to store end execute generated native code, then > Boost.Interprocess's memory mapped files fill probably suit you better. > Shared libraries contain a lot of headers, helper data for load and a bunch > of other stuff that would be really hard to generate. > I don't write an interpreter (I'm really just managing plugins) but I didn't know that, it seems useful in some other contexts. Thanks for the pointer.

1 0

Fwd: [Boost-users] Boost.DLL formal review is ongoing
by Antony Polukhin 04 Jul '15

04 Jul '15

2015-07-04 0:16 GMT+03:00 Klaim - Joël Lamotte <mjklaim(a)gmail.com>: > > > On 3 July 2015 at 15:50, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: >> >> - What's your evaluation of >> - Design >> > > I consider the solutions provided to solve each usual issue with plugin > systems to be simple > and clear, easy to use (as long as you understand what loading plugins > imply). > > Until I check in some complex cases, I think the design is very good. > The symbol name magic might be tricky to understand sometime but it's an > issue which is a side effect of providing > a simple tool to manage symbole names, so it's still good. > > One thing I was wondering: would it be possible to provide a way to load > shared libraries from > raw memory? Or does the OS APIs all requires that the library have to be > on a file sytem? > Unfortunately, there's no portable way to load libraries from raw memory. However you can always mount a filesystem that directly maps to memory (for example Tmpfs on Linux) and store your data in there. This may look like a big performance overhead, but actually loading a shared library takes much time so you won't probably notice the overhead of additional create_file + memcpy. If you're planing this feature to write interpreters\JIT compillers and you just need a place to store end execute generated native code, then Boost.Interprocess's memory mapped files fill probably suit you better. Shared libraries contain a lot of headers, helper data for load and a bunch of other stuff that would be really hard to generate. -- Best regards, Antony Polukhin

1 0

[next gen futures] Lightweight monad ready for inspection
by Niall Douglas 03 Jul '15

03 Jul '15

Some may remember the thread starting from http://boost.2283326.n4.nabble.com/next-gen-future-promise-What-to-cal l-the-monadic-return-type-td4676039.html and that I would firstly prepare an optimally lightweight monad<T> for review here before going on to base a next-gen lightweight future-promise on that monad<T>. I didn't expect it would take nearly four weeks to get there, but writing STL quality C++ with full conformance test suite is amazingly labourious. Anyway you can now view the design and tell me what you think. A quick overview of the design: This monad can hold a fixed variant list of empty, a type R, a lightweight error_type or a heavier exception_type at a space cost of max(20, sizeof(R)+4). Features: * Very lightweight on build times and run times up to the point of zero execution cost and just a four byte space overhead. Requires min clang 3.2, GCC 4.7 or VS2015. A quick sample of runtime overhead, min to max opcodes generated by GCC 5.1: 1 opcodes <= Value transport <= 113 opcodes 8 opcodes <= Error transport <= 119 opcodes 22 opcodes <= Exception transport <= 214 opcodes 4 opcodes <= then() <= 154 opcodes 5 opcodes <= bind() <= 44 opcodes * Just enough monad, nothing more, nothing fancy. Replicates the future API with a fair chunk of the Expected<T> API, so if you know how to use a future you already know how to use this. * Enables convenient all-noexcept mathematically verifiable close semantic design, so why bother with Rust anymore? :) * Can replace most uses of optional<T>. * Deep integration with lightweight future-promise (i.e. async monadic programming) also in this library. * Comprehensive unit testing and validation suite. * Mirrors noexcept of type R. * Type R can have no default constructor, move nor copy. * Works inside a STL container, and type R can be a STL container. * No comparison operations nor hashing is provided, deliberately to keep things simple. Documentation page: https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.S pinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1l ightweight__futures_1_1monad.html Source code: https://github.com/ned14/boost.spinlock/blob/master/include/boost/spin lock/monad.hpp Online wandbox compiler: http://melpon.org/wandbox/permlink/cnZM5KRNpjErXrPH Any opinions or thoughts gratefully received, particularly if I have the exception safety semantics right (i.e. a throw during move or copy leaves the monad empty). Do you also like the polymorphic bind() and map() which does different things depending on the parameter type your callable takes? Do you like that by simply changing the callable's type to a rvalue reference you can move state, or is this being too clever? This monad will become the basis of lightweight future-promise which is essentially a "split monad" with the setter interface and getter interface potentially in different system threads. The then(), bind() and map() work as here but only are triggered at the point of the value being changed. This effectively makes the lightweight future a "lazy continued monad". That lightweight future-promise will then enter AFIO to replace its async_io_op type hopefully in time for the peer review this time next month. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 42

Re: [boost] Boost.DLL formal review is ongoing
by Ralf Globisch 03 Jul '15

03 Jul '15

Hi, Firstly, thanks Anthony for submitting this useful library to boost, and to Vladimir for managing the review. - Should the library be accepted? Yes. I had been meaning to test the library for some time, and with the review reminder finally made some time to do so. My vote of yes is based on my (limited) positive experience with the library, as well as having followed past related discussions on the mailing list, in which many questions are addressed. (http://lists.boost.org/Archives/boost/2014/09/216650.php) I think boost.DLL should be accepted unless someone has a serious/valid reservation as to why this library should not to be accepted. - How useful is it? Very useful. It enabled me to add a test-plugin mechanism to an existing application (Windows and Linux) in a matter of minutes. - What's your evaluation of - Design Looks good to me. Simple to use, with good integration into rest of boost (e.g. file_system). I like the fact that the library is header only and minimal effort was required to integrate plug-in like functionality into an existing application. - Implementation I'm not knowledgeable enough to comment on this. - Documentations Good, the tutorials made it fairly easy to get going and covered my common usage scenarios Code is well commented. - How much effort did you put into your evaluation? About three hours worth of effort, reading through documentation and source code, and using library to create a very simple plug-in mechanism in an existing application. Tested basic plug-in functionality on Windows and Linux. - Did you attempt to use the library? On what systems and compilers? Yes -Linux Ubuntu 14.10 with gcc 4.9.1 with boost 1.57 -Window 7 64-bit with VS 2013 community edition with boost 1.58. Initially made the mistake of not checking the boost version (which had been 1.53 and caused lots of compilation errors.) Minor typo in documentation: Just above the "Full Sources" for tutorial 4 "If we want o make a traditional" should be "If we want to make a traditional" Regards, Ralf >>> Vladimir Prus <vladimir.prus(a)gmail.com> 07/03/15 3:52 PM >>> The formal review of Boost.DLL library by Antony Polukhin is nearing the end of the first week. As of today, over 100 people read through the library's tutorial, suggesting quite some interest. However, no reviews were submitted yet. Please take the time to post your thoughts - even if you don't have time to do a full review, or try the library, comments on design and interfaces are still very valuable. The summary of the library features and review checklists are reproduced below. Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol The documentation can be found at: http://apolukhin.github.io/Boost.DLL/index.html and the source can be obtained at: https://github.com/apolukhin/Boost.DLL Please post your reviews on the mailing list and if possible, answer the following questions: - Should the library be accepted? - How useful is it? - What's your evaluation of - Design - Implementation - Documentations - Tests - How much effort did you put into your evaluation? - Did you attempt to use the library? On what systems and compilers? Thanks, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email.

1 0

Metaprogramming: parameter pack expansion/evaluation trick
by Antony Polukhin 03 Jul '15

03 Jul '15

Hi, Straight to the problem. Consider the situation, were a function accepts parameter pack and something need to be done with each argument (for example, we want to print each argument on a new line): template <typename... Args> void print(Args&&... a) { // print each a on a separate line } There's a known trick to do that: template <typename... Args> void print(Args&&... a) { (void) (int []){ 0, (std::cout << a << std::endl, 0)... }; } But the syntax is not very readable (and I always forget it and search for an example in Internet). I've tried to improve the syntax, and here's the result: template<typename... Args> void print(Args&&... a) { expand_if<Args...> { std::cout << a << '\n'... }; } Compete source could be found here: http://coliru.stacked-crooked.com/view?id=c2c59f22574671e5 Here's some more usage examples: template<typename... Args> void printer_int(Args&&... args) { expand { std::cout << std::abs(args) << std::endl..., std::cout << "Printing once again all the numbers: " << std::endl, std::cout << " Once again " << std::abs(args) << std::endl..., std::cout << "EOF Printing once again all the numbers." << std::endl }; } template<typename... Args> float sum(Args&&... args) { float res = 0; expand_if<Args...> { res += args... }; return res; } I hope this would be helpful for someone or it could be used as an argument for a proposal to extend C++ and allow simpler syntax: template<typename... Args> void print(Args&&... a) { std::cout << a << '\n'...; } P.S.: There was a nicer solution that newer required "_if<Args..>" : namespace detail { struct expand_impl final { template <class... Arg> constexpr inline expand_impl(Arg&&...) noexcept {} }; } template <class... Arg> using expand = detail::expand_impl; But unfortunately there's no way to force the compiler to evaluate expressions in constructor call from left to right. So it did not work on GCC (but work on Clang). -- Best regards, Antony Polukhin

4 4

[math][website] SVG graphics all missing?
by John Maddock 03 Jul '15

03 Jul '15

It looks like all the SVG graphics used by the Boost.Math docs are missing from the website - is this a release SNAFU? Thanks, John.

1 1

[winapi] Major changes in develop
by Andrey Semashev 02 Jul '15

02 Jul '15

Hi, I've just merged a largely reworked version of Boost.WinAPI to develop. It fixes a few bugs and also changes the implementation for better conformance with the C++ standard. Hopefully, it should fix compilation issues with clang on Windows. Another significant change is that Boost.WinAPI targets Windows Vista and later by default. As before, it is possible to explicitly select another version to target by defining BOOST_USE_WINAPI_VERSION. For example, to build Boost for Windows XP one would invoke: b2 define=BOOST_USE_WINAPI_VERSION=0x0501 If anyone has problems with this change, please let me know.

2 5

[optional] How to use optional to lazy construct obj?
by Mostafa 01 Jul '15

01 Jul '15

I'm interested in doing something along the lines of: lazy_adaptor<obj_type> lz(arg1, arg2, arg3, ...) where then lz.construct() then constructs an object of obj_type with ctor of arguments "arg1, arg2, arg3, ...". So far I have the following: (Am I on the right track?) #include <utility> #include <tuple> #include <string> #include <boost/optional/optional.hpp> template <typename... Args> struct ctor_forwarder; template <typename... Args> ctor_forwarder<Args...> make_ctor_forwarder(Args&&... args) { // Note: The "Args..." template parameter to ctor_forwarder determines how // the caller's arguments are temporarily stored. If it's an rvalue, it's // temporarily stored by value, else it's temporary stored by reference. return ctor_forwarder<Args...>(std::forward<Args>(args)...); } template <typename... Args> struct ctor_forwarder { //TODO: make ctor private. template <typename... A> explicit ctor_forwarder(A&&... args) : m_args( ::std::forward<A>(args)... ) {} /* template <typename Callable> auto forward_to(Callable && caller) -> decltype( caller(::std::forward<Args>(m_args)...) ) { return caller(::std::forward<Args>(m_args)...); } */ template <typename T> void forward_to(::boost::optional<T> & obj) { obj.emplace(::std::forward<Args>(m_args)...); } private: typedef ::std::tuple<Args...> args_t; private: args_t m_args; }; template <typename Obj, typename... Args> struct lazy_adaptor { Obj on_enter() { m_args_forwarder.forward_to(m_obj); } private: ::boost::optional<Obj> m_obj; ctor_forwarder<Args...> m_args_forwarder; }; template <typename Obj, typename... Args> lazy_adaptor<Obj, Args...> make_lazy_adaptor(Args&&... args) { return lazy_adaptor<Obj, Args...>(); } struct Sample1 { Sample1(int num, std::string str) {} }; int main() { auto df = make_ctor_forwarder(10, "Ten"); //ctor_forwarder<int, std::string> df(10, "Ten"); auto lazy_ctor = make_lazy_adaptor<Sample1>(10, "Ten"); return 0; }

1 0

Fwd: [SORT] Parallel Algorithms
by Francisco José Tapia 01 Jul '15

01 Jul '15

Hi Steven I had been revising and testing spreadsort, and the results are impressive. I have prepared the benchmarks and include spreadsort. Now the numbers are extracted from a file generated with a random number generator. In a few days I will put all in a git repository for a easy access As I had seen, you use boost::sort for to invoke to spreadsort. If you use this name, which name use for to invoke introsort? I think a good idea can be call the algorithms by their name. If we do this we have the next algorithm list : - spreadsort - spreadsort_integer - spreadsort_float - spreadsort_string - introsort - parallel_introsort - smart_merge_sort - parallel_stable_sort - sample_sort I think it's a simple and easy to understand, because with the name sort, many people think about an algorithm as introsort ( general , not specific for several data types) and not stable. What's your opinion ?

3 19

[Boost] [Hana] Formal review for Hana (Submissions closed)
by Glen Fernandes 30 Jun '15

30 Jun '15

Dear Boost community, The period for Hana review submissions has ended. The result will be announced on the list during this week. I would like to thank everyone on this list for your submission of a review: - Edouard Alligand - John P. Fletcher - Niall Douglas - Krzysztof Jusiak - Roland Bock - Vicente J. Botet Escriba - David Sankel - Zach Laine - Kohei Takahashi - Charley Bay - Bruno Dutra - Christophe Henry - David Stone - Lorenzo Caminiti - John Bytheway - Manuel Sánchez As well as the following people for your discussion during the review period: - Phil Endecott - Larry Evans - Abel SInkovics - Gavin Lambert - Jeremy Maitin-Shepard - Joel de Guzman - Edward Diener - Paul A. Bristow - Peter Dimov - Bjorn Reese - Paul Fultz II - Lee Clagett Once again, thank you to Louis for all your work on Hana and submitting it for Boost inclusion. Glen

2 1

[Circular Buffer]Could erase_begin run in constant time for trivially destructible objects?
by Pradhan Kumar 30 Jun '15

30 Jun '15

Hello everyone, The implementation of circular_buffer<T>::erase_begin(n) is tag-dispatched on is_scalar<T>, to use a constant time implementation for scalar types. For non-scalar types, it falls back to using rerase(begin(), begin()+n). Could we change this to dispatch on std::is_trivially_destructible? Examining the generated code, I see that the below loop has not been completed optimized out for a POD-type. (I am using Boost 1.58 and gcc4.9.2. The compile option was g++ -O3 -std=c++11 -g -DBOOST_CB_DISABLE_DEBUG -fno-inline to make it easier for me to understand the assembly.) do { destroy_item(m_first); increment(m_first); --m_size; } while(m_first != p); destroy_item is optimized out, as expected. However, increment has a "modulo" check and this prevents the above while loop from getting optimized to one instruction. template <class Pointer> void increment(Pointer& p) const { if (++p == m_end) p = m_buff; } Thoughts? Thanks, Pradhan

1 0