- Boost - lists.boost.org

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