- Boost - lists.preview.boost.org

Re: [boost] invalid access to stack memory?
by alexc 11 Feb '17

11 Feb '17

Original Message Sender:Bjorn Reese via Boostboost(a)lists.boost.org Recipient:boostboost@lists.boost.org Cc:Bjorn Reesebreese(a)mail1.stofanet.dk Date:Saturday, Feb 11, 2017 19:39 Subject:Re: [boost] invalid access to stack memory? On 02/11/2017 08:47 AM, alexc via Boost wrote: followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? From a quick look at the code, I do not think that it poses a problem. The idea, as I understand it, is to use RAII to push and pop a "stack frame" (call_stackT::context) onto a thread-local static "stack" (call_stackT::top_.) The context destructor will remove itself from the "stack". Oh, context class “recover” thecall_stackT::top_ indestructor, I miss this in the first place, thank you, Bjorn, it’s a very cool idea to me. _______________________________________________ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] invalid access to stack memory?
by Bjorn Reese 11 Feb '17

11 Feb '17

On 02/11/2017 08:47 AM, alexc via Boost wrote: > followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? From a quick look at the code, I do not think that it poses a problem. The idea, as I understand it, is to use RAII to push and pop a "stack frame" (call_stack<T>::context) onto a thread-local static "stack" (call_stack<T>::top_.) The context destructor will remove itself from the "stack".

1 0

invalid access to stack memory?
by alexc 11 Feb '17

11 Feb '17

Hi all, followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? detail/call_stack.hpp explicit context(Key* k) : key_(k), next_(call_stackKey, Value::top_) { value_ = reinterpret_castunsigned char*(this); call_stackKey, Value::top_ = this; // == store this to a static variable } detail/impl/strand_service.ipp void strand_service::do_complete(io_service_impl* owner, operation* base, const boost::system::error_code ec, std::size_t /*bytes_transferred*/) { if (owner) { strand_impl* impl = static_caststrand_impl*(base); // Indicate that this strand is executing on the current thread. call_stackstrand_impl::context ctx(impl); // == local variable ctx, its this pointer will be stroed in a static variable. Regards, Alex

1 0

Review Request : Boost.SIMD
by Joel FALCOU 10 Feb '17

10 Feb '17

Can Boost.SIMD please be added to the review queue? Michael Caisse has volunteered to act as the review manager. Boost.SIMD is an efficient modern C++ wrapper for SIMD instructiosn sets and computations that aims at providing a standard way to write code taking advantages of SIMD enabled hardwares. Boost.SIMD repository https://github.com/NumScale/boost.simd Documentation https://developer.numscale.com/boost.simd/documentation/develop/ Thanks in advance Joel Falcou - CTO @ NumScale

6 8

Testing DMARC spam binning
by Niall Douglas 10 Feb '17

10 Feb '17

Dear Boost, You all probably noticed that boost-dev now sends you emails from "Your Name via Boost <boost(a)lists.boost.org>" with your original email listed as CC. This should finally mean that DMARC protected email addresses are no longer flagged as Spam by many email services, including this email from me, as boost-dev is no longer sending email with a protected From: address. The list should be made aware that fixing this has taken nine months or so for good reason. A whole ton of work went into making this happen, not least relocating Boost's mailing list services from wowbagger where it had been for almost forever to new hosting partially donated to us for free. What wasn't obvious here was that there were problems of ownership transfer, arranging service donation and the change over and getting many, many long seized up cogs to turn, ones indeed I have failed to turn in many years of trying myself. The fact it all happened without service interruption is an amazing achievement. I'd like to ask the list to formally thank Michael Caisse and his team of many diligent workers who did all of this just to get mail posted here to not get flagged as Spam (there were other motivating factors too of course, but the Spam issue got the ball rolling). It was an awful lot of work for not a very obvious gain here on boost-dev. So thank you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1

Re: [boost] Requirements: min and max macros
by Bjorn Reese 07 Feb '17

07 Feb '17

On 02/05/2017 06:15 PM, Vinnie Falco wrote: > From > http://www.boost.org/development/requirements.html#Naming > > "Make sure your code compiles in the presence of the min() and max() > macros. Some platform headers define min() and max()macros which cause > some common C++ constructs to fail to compile. Some simple tricks can > protect your code from inappropriate macro substitution:..." Is this guideline still relevant?

4 4

[gsoc17] Attn: We need 2017 mentors and project ideas for Boost!
by Niall Douglas 07 Feb '17

07 Feb '17

Dear Boost community, We are now a few weeks from the beginning of Google Summer of Code 2017! Last year we had the big surprise of being rejected by Google as an org, the second time ever, on the basis that Google felt we needed a year off. Thanks to the quick actions of the Boost Steering Committee and IMC Financial Markets we managed to put together a "Boost Summer of Code" so the students with projects in progress would not be left stranded. Despite a fair few teething problems, I think that worked out okay. As part of filling in our application for 2017, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2017 in order to be approved as an organisation this year. Therefore a lengthy page of awesome project ideas at https://svn.boost.org/trac/boost/wiki/SoC2017 before *February 9th* would be an enormous help to getting us approved again this year and bringing to Boost another US$35,000 of Google funding. If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. The year before last we had more slots awarded to us by Google than we had good combinations of student and mentor, so we had to return slots which I believe has not happened here at Boost GSoC in at least a decade. That means that your project ideas have a better chance than ever of receiving funding if you can find a good student, and that is best done by getting project ideas floated *early*. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org or via gsoc-admin(a)boost.org. Thank you in advance for your time.

1 1

[interprocess] Fix doc build ASAP
by Rene Rivera 07 Feb '17

07 Feb '17

This commit < https://github.com/boostorg/interprocess/commit/936afb13f0c106728bcf36c1ce1…> seems to have broken the release archive documentation build: Generating Output File: /home/ubuntu/build/boost/bin.v2/libs/interprocess/doc/docbook/gcc-4.9.2/debug/interprocess.xml /home/ubuntu/boost/libs/interprocess/doc/interprocess.qbk:7421: error: Mismatched [endsect] near column 9. Error: Error count: 1. Please fix ASAP. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[GIL] Bringing old bug fixes on development branch into regular boost releases
by Marcel Metz 06 Feb '17

06 Feb '17

Hello boost devs, I'm a user of the Boost.GIL library and maintained a fork inside inside another project because GIL lacked some features at that time this project needs. This GIL fork happened with boost release 1.37. After reviewing the changes recently it turned out that those can be implemented without maintaining a dedicated GIL fork. However when building the project with the upstream GIL library some compiler specific build bugs popped up. It seems like the forked GIL version already had fixes for those whereas the upstream Boost.GIL doesn't. Further investigation showed that some of those were fixed years ago in the GIL development branch, but never made it back into the master branch (and as far as I understand master is used for release tags). All of those were reported: #3908 - using boost::gil fails when upgrading to libpng-1.4.0 #7270 - C++11 narrowing problem in gil #8896 - image_view compile error under clang 3.1 #9517 - boost gil compile error because of type narrowing (dup of #7270) Is it possible for the maintainer to cherry-pick the corresponding commits from development onto master and put them into the next boost release or are there other steps involved that prevent the bug fix inclusion? Regards Marcel

2 1

[Fit] Update: Request for feedback
by Paul Fultz II 06 Feb '17

06 Feb '17

Hi, I have made a lot of updates to the Fit library based on the changes suggested during the review earlier this year. I have also improved the documentation. I have expanded on the introductory materials and have add a lot more cross-referencing. The documentation can be found here: http://fit.readthedocs.io <http://fit.readthedocs.io/> Let me know of any feedback about the library either here on the mailing list or on Github issues. Thanks, Paul

4 9

Requirements: min and max macros
by Vinnie Falco 05 Feb '17

05 Feb '17

From http://www.boost.org/development/requirements.html#Naming "Make sure your code compiles in the presence of the min() and max() macros. Some platform headers define min() and max()macros which cause some common C++ constructs to fail to compile. Some simple tricks can protect your code from inappropriate macro substitution:..." There is one case not addressed. What to do with this: std::min<std::size_t>(a, b); ?

3 2

[build] Pre-built libraries and targets
by Edward Diener 04 Feb '17

04 Feb '17

In a jamfile I have: lib user32 ; lib gdi32 ; exe test1 : main.cpp user32 gdi32 ; According to the Boost Build documentation the 'lib' syntax above refers to pre-built libraries, and not libraries I mean to build as a shared or static library. When I run b2 with a particular toolset, and use the --debug-building option to see what targets are being built, I see results of: Building target '../../../libs/test_local/build/user32'... and Building target '../../../libs/test_local/build/gdi32'... Furthermore the build of the test1.exe does not add the user32 or gdi32 pre-built libraries to the linker command line. Can anyone tell me why Boost Build is attempting to build a target for a library which I specify as a pre-built library ?

1 0

Call for Submissions: International Conference on Information Society (i-Society 2017) || July 17-19, 2017, Dublin, Ireland
by David Brown, i-Society 2016 03 Feb '17

03 Feb '17

1 0

Mail Lists Migrate at 00:00 UTC Feb 3
by Michael Caisse 02 Feb '17

02 Feb '17

The following mail lists will be switched to new infrastructure at 00:00 UTC on February 3rd. There will be a small interruption while the DNS/MX records propagate. * Boost - Boost developers' mailing list * Boost-announce - Boost announce-only mailing list * Boost-bugs - Bugs reported/updated through Boost's Trac * Boost-build - Boost.Build developer's and user's list * Boost-cmake - Discussion of the CMake-based build system for Boost * Boost-commit - Boost Subversion commit messages * Boost-docs - Discussion of Boost Documentation * Boost-Interest - Moderated announcements of interest to the Boost community. * Boost-maint - Boost community maintenance mailing list * Boost-mpi - Discussion of Boost.MPI development * Boost-test - Test list for the boost mailing lists * Boost-Testing - Running Boost regression tests * Boost-users - Boost Users mailing list * Geometry - Boost.Geometry library mailing list * glas - Generic Linear Algebra Software * proto - Discussions about Boost.Proto and DSEL design * threads-devel - Discussions about the boost.thread library * ublas - ublas mailing list -- Michael Caisse Ciere Consulting ciere.com

1 0

[factory][bind] C2664 with MSVC 2015 & 1.63
by Jens Weller 02 Feb '17

02 Feb '17

Hello Boost, I'm having this Problem: http://lists.boost.org/boost-users/2015/04/84176.php That message already describes pretty much what I see, except that I use 1.63 and the latest 2015 VC++. Errormessage: D:\cpp\libraries\boost_1_63_0\boost\bind\bind.hpp:388: error: C2664: 'ListsModuleWidget *boost::factory<ListsModuleWidget *,void,boost::factory_alloc_for_pointee_and_deleter>::operator ()(void) const': cannot convert argument 1 from 'Module *' to 'Module *&' bind.hpp code: > template<class R, class F, class A> R operator()(type<R>, F & f, A & a, long) > { > >>this line return unwrapper<F>::unwrap(f, 0)(a[base_type::a1_], a[base_type::a2_], a[base_type::a3_]); > } Compiler says: ..\..\..\..\cpp\libraries\boost_1_63_0\boost/bind/bind.hpp(388): error C2664: 'ListsModuleWidget *boost::factory<ListsModuleWidget *,void,boost::factory_alloc_for_pointee_and_deleter>::operator ()(void) const': cannot convert argument 1 from 'Module *' to 'Module *&' ..\..\..\..\cpp\libraries\boost_1_63_0\boost/bind/bind.hpp(1342): note: see reference to function template instantiation 'R *boost::_bi::list3<boost::arg<1>,boost::arg<2>,boost::arg<3>>::operator ()<ListsModuleWidget*,F,boost::_bi::rrlist4<A1,A2,A3,A4>>(boost::_bi::type<ListsModuleWidget *>,F &,A &,long)' being compiled with [ R=ListsModuleWidget *, F=boost::factory<ListsModuleWidget *,void,boost::factory_alloc_for_pointee_and_deleter>, A1=Module *, A2=const QString &, A3=const QString &, A4=QWidget *, A=boost::_bi::rrlist4<Module *,const QString &,const QString &,QWidget *> ] cheers, Jens Weller

2 4

[outcome] Feedback on parts A and B of Tutorial mk III requested
by Niall Douglas 02 Feb '17

02 Feb '17

Dear Boost, I am truly hoping that this will be the last time I ask for feedback on Outcome's tutorial as this is the third complete rewrite. Many thanks for all the feedback so far, this Mk. III tutorial wouldn't look like this without all your help. Part A is 100% on pure expected<T, E> as currently before the standards committee. It has nothing to do with Outcome, but places Outcome in context. Part B is a polemic on why people should not use arbitrary type E in expected<T, E> and instead should restrain themselves to either E = std::error_code or E = std::exception_ptr. I'm requesting feedback on parts A and B of the tutorial which I think are mostly complete now. Specific feedback on these topics is particularly welcomed: 1. I've tried to make some of the code examples in Part A less contrived. Are there any obviously specific additional things I can do (note Parts B and C have more realistic programs)? 2. Are you convinced by the end of Part B that using arbitrary types for type E is a bad idea? If not, what did I fail to do in my explanation? Many thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 5

filtering_streambuf: Compressing a character buffer
by Adlai Shawareb 02 Feb '17

02 Feb '17

Hi, I have a character buffer ( "buffer" ) of known size ( "size_in_bytes" ), and would like to compress it using gzip_compressor and then get a pointer to the compressed buffer along with the compressed size. I've put together the following, but it says the first counter is 0 and the second counter is 2. Any help that can be offered is appreciated. namespace io = boost::iostreams; boost::asio::streambuf sb; std::ostream os(&sb); os.write( buffer, size_in_bytes ); io::filtering_streambuf<boost::iostreams::output> out; out.push(io::counter()); out.push(io::gzip_compressor()); out.push(io::counter()); out.push(os); io::close(out); // Needed for flushing the data from compressor std::ostream output(&out); // Maybe I can use rdbuf() to get the pointer to the stream?

1 0

[type_erasure] Inefficient extra shared_ptr copy when passing parameter of type _self
by Yuanchen Zhu 01 Feb '17

01 Feb '17

Hi List, I have been using boost::type_erasure a bit. I found that in the case of implementing equality_comparable, when it passes into operator== a placeholder argument corresponding to some any<C, T>, it always wraps it in a param<C, T>, which internally instantiates an any<C, T&>. While this instantiation does not cause the actual content to be copied, it always clone the share_ptr pointing to the dispatch table, causing an extra shared_ptr construct/destruct invocation whenever I do an equality comparison. This source of inefficiency seems unnecessary to me. Is it possible to modify param<C, T> such that it only stores non-ref counted raw reference to the original argument? Of course the functions in type_erasure::detail::access need to be updated accordingly. Will this modification break some grander scheme underlying type_erasure that I am unaware of, being new to the code base? It seems to me that when param<C, T> wraps a temporary, the temporary is guaranteed to live past the lifetime of the invocation. Can people vet this idea before I take a stab at changing the code? Thanks, Yuanchen

1 0

[serialization][uBlas] Serialization still breaking anything that uses uBlas?
by John Maddock 01 Feb '17

01 Feb '17

See for example: http://www.boost.org/development/tests/develop/developer/output/teeks99-02-… I'd really like to get these failures off my radar if possible... Thanks, John.

2 1

[testing] Need optimization help!!!
by Rene Rivera 01 Feb '17

01 Feb '17

If someone is interested in an optimization challenge here's your opportunity. Currently the program(s) that generate the test results take a long time to run. In both the live setup of a 4 core 16 GB ram VM it takes about 40 minutes to generate the reports for master and develop branches. On my 4 core 16 GB ram real hardware SSD HD machine it also takes about 40 minutes. If some brave soul could look into why it's so terribly slow the Boost community would be very grateful. As it would make it possible to move the processing to a CI service and improve results reliability and frequency. Unfortunately the only price I can promise for such a task is to buy you a meal and/or some drinks if I see you :-) If you are interested all that's needed to run the results is: a) A good chunk of disk space.. At least 27GiB. b) A bash shell, and Python, and git, and C++ tools (but you probably already have all that). b) An empty directory to run the reports. c) Download this script < https://github.com/boostorg/regression/blob/develop/reports/src/build_resul… >. d) Comment out the upload commands on lines 220-223. e) Run the script, and wait. And then the fun part of finding out what programs get run and what is slow :-) FYI.. The source for the processing is downloaded by the script. But you can find it here < https://github.com/boostorg/regression/tree/develop/reports>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 10

Re: [boost] Is there any interest in non-owning pointer-like types?
by Joseph Thomson 01 Feb '17

01 Feb '17

On 1 Feb 2017 7:51 p.m., "Olaf van der Spek" <ml(a)vdspek.org> wrote: On Wed, Feb 1, 2017 at 12:39 PM, Oswin Krause <Oswin.Krause(a)ruhr-uni-bochum.de> wrote: > On 2017-02-01 12:02, Olaf van der Spek wrote: >> >> On Wed, Feb 1, 2017 at 11:24 AM, Oswin Krause >> <Oswin.Krause(a)ruhr-uni-bochum.de> wrote: >>> >>> For me, the biggest problem of the proposal is that observer_ptr<T> is >>> implicitely constructed from T&. In my code I often use: >>> >>> Foo a; >>> Bar b(&a);//&a signals that b only references to a, but does not copy it. >>> >>> Now, when I write >>> >>> Bar b(a); //so is a now copied? >>> >>> While the interface is clearer in documentation, the usage is less clear! >> >> >> IMO using pointers instead of references to indicate something isn't >> copied is bad practice.. the language is C++, not C. > > > > This is not a C vs C++ thing. > > But assume it was. How would you indicate that in C++? It should be clear > without looking at the reference whether it is okay for a to go out of scope > before b or not. There's no way to indicate that, AFAIK. The way to indicate it is to require explicit conversion from `T&` to your pointer-like type. `make_observer` can play the role of a type-safe `&`. I would be happy to remove implicit conversion from `T&` if it is agreed to be undesirable. Joseph

1 0

Re: [boost] Boost XML Serialization Stability across library versions
by Adlai Shawareb 01 Feb '17

01 Feb '17

Thanks Robert, Regarding your suggestion to use text serialization. Since, over time, we will be adding and deleting data from the data set that we serialize, would the following be the right approach to managing the changes in the data that is de/serialized. I'm thinking that we would set the BOOST_CLASS_VERSION before de/serializing. { ar & mInt; If(version >= 2) ar & mFloat; If(version >= 3) ar & mInt2; ar & mFloat2; } Regards, Adlai On 1/25/17 12:04:00, Robert Ramey wrote: > Right. No one as under taken that task. Should be fairly straight > forward using spirit v3. > Robert Ramey

2 3

[container] ::flat_map function force_copy break strict-aliasing on gcc < 4.4
by Владислав Щапов 31 Jan '17

31 Jan '17

Hello! On function: template<class D, class S> BOOST_CONTAINER_FORCEINLINE static D force_copy(S s) { D *vp = reinterpret_cast<D *>(&s); return D(*vp); } gcc 4.3.4 (SLE 11) produced wrong code. It seems that the compiler does not create a copy of an object "s" and returns an object of D(). If I change the signature of function on "BOOST_CONTAINER_FORCEINLINE static D force_copy(const S& s)" the code works and the tests pass. But then does not create a copy of an object "s" in a function call. I'm not sure that this change is correct. Is there any other workaround for this problem with a compiler gcc 4.3 or better disable strict-aliasing? -- Best regards, Vladislav

2 2

C++Now 2017 Registration is Open
by Jon Kalb 31 Jan '17

31 Jan '17

Boost Devs, Registration for C++Now 2017 is now open: http://bit.ly/CppNow2017IsOpen The conference will be in Aspen, Colorado from May 15th to 20th. The deadline for submissions is this Friday: http://cppnow.org/2017-conference/announcements/2017/01/06/call-for-submiss… Jon

1 0

[CallableTraits] Still seeking Review Manager
by Barrett Adair 31 Jan '17

31 Jan '17

Hi, I'm still seeking a review manager for my CallableTraits library. I have spent hundreds of hours on this library, most of which went toward documentation and cross-platform testing. I think a small subset of the features in CallableTraits belong in the C++ standard. Occasionally at work, I have wished this were in Boost already. In short, this library eliminates the need to specialize templates for function signatures, and accounts for the *many* corner cases and cross-platform quirks that most users never care to do thoroughly themselves. I have 9 issues remaining on the GitHub page that would be resolved before an eventual acceptance, and I'd like to write some additional tests and documentation, but I think this library is ready for a review manager. Would anyone like to volunteer? https://github.com/badair/callable_traits Thanks, Barrett

1 0

[regression] Are tests not running?
by Andrey Semashev 31 Jan '17

31 Jan '17

Hi, Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?

6 16

Re: [boost] [sort] pdqsort
by Orson Peters 30 Jan '17

30 Jan '17

Hi, Orson here, I'm the original author of pdqsort. As discussed in this long github issue ( https://github.com/boostorg/sort/issues/11) I have full copyright on the pdqsort implementation (which is freely available under the zlib license on https://github.com/orlp/pdqsort) and am willing to provide it to Boost free of charge under the Boost license. @Marc Glisse, since your 2015 experiment the code has changed, and pdqsort now uses a technique called block quicksort. It's substantially faster for branchless comparisons (50-80%), but it seems that on some systems it also give significant (5-15%) slowdowns for branchful code. I will revert pdqsort's default implementation to the old version, except when the passed in type is built-in, and the comparison operator is std::less / std::greater, then I will use the branchless code. I will provide the branchless code explicitly as well, under a different function name, for experienced users that know their comparison function is branchless. The old implementation was never slower than std::sort in my experiments, for the record. If any of you have further questions, please do let me know.

2 1

[rational] Compilation issues on VS2013+
by Raffi Enficiaud 30 Jan '17

30 Jan '17

Hi Boost, I am having the following issues when compiling boost.test on develop: http://www.boost.org/development/tests/develop/developer/output/teeks99-09e… It seems that the problem is related to rational (worked for the 1.63 release), but I am not sure. Thanks! Raffi

1 0

[Beast] WebSocket is now feature-complete!
by Vinnie Falco 29 Jan '17

29 Jan '17

I'm pleased to announce that Beast 1.0.0-b24 has been pushed to the master branch, making Beast's WebSocket implementation feature complete with respect to RFC 6455 ("The WebSocket Protocol") and draft-ietf-hybi-permessage-compression-28 ("Compression Extensions for WebSocket). The latest version adds support for the "permessage-deflate" extension, which allows WebSocket messages to be compressed using the deflate algorithm. Beast comes with a header-only port of ZLib to modern C++11, no additional library is necessary to use the extension. The library now passes every test in the Autobahn TestSuite including compression tests. Official Repository https://github.com/vinniefalco/Beast/ Documentation http://vinniefalco.github.io/beast/index.html Autobahn TestSuite results http://vinniefalco.github.io/autobahn/index.html Thanks! -- Follow me on Github: https://github.com/vinniefalco

3 2

[Boost.Lockfree] Interest in a ringbuffer class
by Raphaël Londeix 27 Jan '17

27 Jan '17

Hi everyone, Is there any interest in having a lower level ringbuffer type in Boost.Lockfree ? The containers provided today in the library can only store homogeneous types of fixed size. At work, we have refined many implementations of ringbuffer classes that allow one to push/pop raw buffers. Before investing some time into a pull request, I wanted to know if there's some interest in such a type. The interface looks like this: template<typename Self, typename... Policies> class basic_ringbuffer { public: typedef ... buffer; public: buffer* start_write(size_t); void commit_write(size_t); void commit_write(buffer const*); buffer const* start_read(); void commit_read(size_t); void commit_read(buffer const*); public: void reader_reset(); void writer_reset(); private: buffer* _ring() { return static_cast<Self>(*this).ring(); } }; Of course, these are only the lowest level methods, one could implement push()/pop() or other higher level methods. Beyond the fact that this API provides by default zero-copy semantics, this interface is also agnostic to the actual owner of the memory, which allow users to implement custom ringbuffers easily (shared memory, mmap trick to map the beginning at the end, etc.), for example: class custom_ringbuffer : basic_ringbuffer<custom_ringbuffer, SomePolicies...> { buffer* ring() { return some_memory; } }; The usage would look like: custom_ringbuffer rb; // the write side if (auto buf = rb.start_write(100)) { memcpy(buf.data, "some data", 9); rb.commit_write(9); } // the read side if (auto buf = rb.start_read()) { std::cout << std::string_view(buf.data, buf.size) << std::endl; rb.commit_read(buf); } What do you think ? Did I miss something in boost itself ? Should I give a more complete overview of the API ? Cheers, -- Raphaël Londeix http://hotgloupi.fr

6 13

[outcome] Requesting second pre-review of Boost.Outcome tutorial
by Niall Douglas 27 Jan '17

27 Jan '17

Dear Boost, Last November you gave me some valuable feedback on rewriting the tutorial for Boost.Outcome, a C++ 14 library providing a factory and family of policy driven lightweight monadic value-or-error transports. I recently came out of employment contract and so have had the time to rewrite Outcome's Tutorial (anyone interested in employing a remote working C++ consultant please do get in contact). I'd appreciate feedback on https://ned14.github.io/boost.outcome/: 1. Is this rewritten tutorial too simple, too detailed or about right? 2. Do you feel you could use Outcome in your own code without difficulty after reading it? If not, what information is missing? 3. Are you persuaded of the merits of using Outcome after reading it? If not, what else do I need to say? The first FOUR sections at https://ned14.github.io/boost.outcome/ have been rewritten by me to hopefully reflect the feedback you gave me last November, so these have been refactored so far: * Description, Prerequisites and Support * Installing, building and testing Outcome * Quick start for the expert * Tutorial The package repo install methods haven't been implemented yet, these are marked in the docs as todo. These sections have yet to be refactored: * Frequently Asked Questions * Advanced usage: Outcome as a Monad * Outcome and the upcoming std::expected<T, E> Many thanks in advance for any feedback received. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

7 20

Why is this message in Spam?
by Olaf van der Spek 26 Jan '17

26 Jan '17

Hi, > Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication. Learn more I think this list isn't configured properly.. and this causes some messages to end up in Spam consistently.. Who's responsible for the mailing list infrastructure? Gr, -- Olaf

7 12

[sort] pdqsort
by Steven Ross 26 Jan '17

26 Jan '17

I've been reviewing a proposed addition to Boost.Sort called pdqsort. When using a general-case partitioning algorithm, it performs comparably to std::sort in my testing (Windows and Linux). When used as a replacement for the std::sort fallback in spreadsort, using a branch-reducing optimization it is ~20% faster on ints and floats, and ~40% slower on strings. The concerning part is that any comparison operator that involves a branch may have a comparable slowdown to the string case. pdqsort is also significantly faster than std::sort on mostly-sorted data and some other (relatively common) special cases. This makes little difference when used as a fallback by spreadsort, but does make a difference when used on its own. I see these possible things to do with pdqsort: 1) Reject it completely as too similar to std::sort, which is already highly optimized. 2) Add it as another optional library in the Boost.Sort library. 3) Add it to Boost.Sort, and only use it as a fallback for ints and floats. 4) Add it to Boost.Sort, use it as a fallback for all of spreadsort, and have pdqsort itself only use its branch-reduction optimization on ints and floats. 5) #4, except eliminate the branch-reduction optimization completely from pdqsort for simplicity. Does anyone have a strong preference, advice, or comments on how they use Boost.Sort? Should I run a mini-review for pdqsort?

5 9

Re: [boost] bad include guards
by Larry Evans 26 Jan '17

26 Jan '17

On 08/21/2007 03:11 PM, Steven Watanabe wrote: > AMDG > > The following pairs of files have identical include guards > > ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp > ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp > ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp > ./boost/interprocess/containers/tree.hpp > ./boost/interprocess/containers/detail/tree.hpp . . . Steven, do you have a program to detect files with identical include guards. I could you one at the moment :) -regards, Larry

4 6

Boost XML Serialization Stability across library versions
by Adlai Shawareb 26 Jan '17

26 Jan '17

Hi, We want to generate an Serialized XML archive now, and be able to deserialize it and get the same data it in the future. Is Boost XML Serialization guaranteed to be compatible across versions of the library? The XML serialized archive would be stored in a memory chip and, in the future, read back and deserialized. I don't believe that would impact the answer, but want to offer that. Adlai

6 12

Moving away from SourceForge
by Louis Dionne 26 Jan '17

26 Jan '17

Hi, I know this has been discussed in the past, but I would like to revive the discussion about moving away from SourceForge as Boosts' release hosting provider. SourceForge has at least the following issues: - There is no way of controlling the format when downloading an archive of the latest release. This can break people that rely on this in their CI scripts. For example, Metabench's[1] CI was broken for a while when the archive changed from .bz2 to .zip. - SourceForge has been in the middle of some controversies[2]. - Their reliability has not been so great. In the past year, I've had quite a few of my Travis jobs fail due to SourceForge being unresponsive. There are most likely other concerns, but these are the ones that really bite me as a user right now. Am I the only one? If there's some push to do the move, the two main candidates I see would be - GitHub's native hosting - Bintray Thoughts? Louis [1]: https://github.com/ldionne/metabench [2]: https://en.wikipedia.org/wiki/SourceForge#Controversies -- View this message in context: http://boost.2283326.n4.nabble.com/Moving-away-from-SourceForge-tp4691184.h… Sent from the Boost - Dev mailing list archive at Nabble.com.

9 17

Boost.Endian - endian_buffer requirements
by Vicente J. Botet Escriba 26 Jan '17

26 Jan '17

Hi, I wanted to put an Int wrapper inside a endian_buffer and I have some compiler errors depending on whether it is aligned ort not. http://melpon.org/wandbox/permlink/k52wH2A7yagL2vMP I was expecting that the endian_buffer would make abstraction of the wrapped type and consider it just as a sequence of bytes, but it seems that it instead works only for some builtin integral. Am I missing something? Was this restriction intended? Could this restriction be removed and if yes, how? Best, Vicente

1 2

[program_options] implicit value and non-adjacent tokens
by Vladimir Prus 25 Jan '17

25 Jan '17

Hi, some time ago, program_options was modified so that options with implicit value would only take value from the same token. Previously, one could have: ./program -a foo -b # uses 'foo' as value for 'a' ./program -a -b # uses some default value for 'a' ./program -b # has no value for 'a' Now, the first syntax interprets 'foo' as positional option, and one has two write ./program -a=foo Ever since, I hear concerns from users about this behavior. Maybe not very loud, but quite consistent. Maybe, the new behavior is not very good, indeed, because it now mixes syntax matter (whether value is in the same token) with semantic matter (whether an option has implied value). I am considering reverting this change for next version of Boost. Does anybody have opinions either way? Thanks, Volodya

3 5

C++Now / BoostCon 2017 -- Call For Submissions
by Michael Caisse 23 Jan '17

23 Jan '17

This is a quick reminder that the C++Now 2017 Call For Submissions is *open*. All submissions must be made by February 3rd. For more information, see http://cppnow.org/

1 0

boost build with emscripten
by Emil Dotchevski 23 Jan '17

23 Jan '17

I see that there is now emscripten support in boost build but it doesn't seem to work for me. After installing emscripten on Windows, adding using emscripten ; in my site-config.jam, then running b2 from the emscripten command prompt, I get the output below. Any help greatly appreciated! Emil boost-build/src/build\property.jam:743: in class(a)property-map.find from module object(property-map)@26 error: Ambiguous key boost-build/src/build\type.jam:333: in generated-target-ps from module type boost-build/src/build\type.jam:270: in type.generated-target-suffix from module type boost-build/src/build\virtual-target.jam:509: in virtual-target.add-prefix-and-suffix from module virtual-target boost-build/src/build\virtual-target.jam:468: in _adjust-name from module object(file-target)@3764 boost-build/src/build\virtual-target.jam:253: in abstract-file-target.__init__ from module object(file-target)@3764 boost-build/src/build\virtual-target.jam:561: in class(a)file-target.__init__ from module object(file-target)@3764 boost-build/src/kernel\class.jam:90: in class.new from module class boost-build/src/build\generators.jam:558: in generated-targets from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:453: in construct-result from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:412: in run-really from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:386: in class(a)generator.run from module object(C-compiling-generator)@138 boost-build/src/build\generators.jam:994: in try-one-generator-really from module generators boost-build/src/build\generators.jam:1056: in try-one-generator from module generators boost-build/src/build\generators.jam:1294: in construct-really from module generators boost-build/src/build\generators.jam:1378: in generators.construct from module generators boost-build/src/build\targets.jam:1553: in construct from module object(typed-target)@3554 boost-build/src/build\targets.jam:1353: in class(a)basic-target.generate from module object(typed-target)@3554 boost-build/src/build\targets.jam:774: in generate-really from module object(main-target)@3735 boost-build/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@3735 boost-build/src/build\targets.jam:895: in targets.generate-from-reference from module targets boost-build/src/build\targets.jam:1266: in generate-dependencies from module object(typed-target)@2173 boost-build/src/build\targets.jam:1323: in class(a)basic-target.generate from module object(typed-target)@2173 boost-build/src/build\targets.jam:774: in generate-really from module object(main-target)@2988 boost-build/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@2988 boost-build/src\build-system.jam:714: in load from module build-system NT\..\..\munch\boost-build\src\kernel\modules.jam:295: in import from module modules NT\..\..\munch\boost-build\src\kernel\bootstrap.jam:139: in boost-build from module NT\..\..\munch\boost-build.jam:6: in module scope from module

3 8

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Ion Gaztañaga 23 Jan '17

23 Jan '17

On 22/12/2016 10:01, Thomas Dahms wrote: > Dear developers, dear Ion, > > We are experiencing issues on Windows where boost::interprocess relies > on a certain event in the system event log to get the system's boot-up > time. This has proven to be unreliable, because that event is not always > present in the log. In that case, initialization of boost::interprocess > fails. > Several bug reports exist for that issue, e.g. [1, 2]. > > Report [1] contains a proposed fix to use GetTickCount64() and there is > an open PR with an alternative fix to fall back to WMI mechanisms [3]. I > understand that the fix [1] would need some polishing, because > GetTickCount64() is not available in pre-Vista. > > Nevertheless, both proposed fixes have been uncommented and unconsidered > for a while now. Is there any chance that the maintainers could look > into this? Thanks for the ping. I don't think GetTickCount64 is very reliable, as other methods also have problems with time correction, hibernation, fast bootup, etc. In [1] one the last bootup log is lost new processes won't be able to communicate with others. The same happens with [3] In http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/acknowledgements… there are some instructions to give up on kernel persistence and define the directory at compile time or run-time. This is the best workaround so far. I've trying to find a solution with no luck. I tried: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId in modern Windows systems but hybrid shutdown (default since Windows 8) does not seem to update it as kernel is suspended. Searching for a unique bootup id in windows that does not suffer when hibernating or correcting the RTC is really complicated. Any suggestion welcomed. Best, Ion

2 1

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 21 Jan '17

21 Jan '17

Hi, The regression matrix in develop of Boost.Geometry contains many new compilation failures due to: 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' 2): ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? ar & serialization::make_array(data_, s);and a The master is still OK. Can this be solved? Regards, Barend

6 9

Boost Cmake Modules
by Paul Fultz II 20 Jan '17

20 Jan '17

Hi All, So I would like to start work with adding support for cmake to boost libraries. To make the boilerplate needed to write some of the cmake, I wrote BCM(Boost Cmake Modules), here: https://boost-cmake.github.io/bcm/doc/html/ Of course, the documentation is still a WIP. The core part is bcm_boost_package. So to write cmake for a library, you would just write something like this: bcm_boost_package(core VERSION 1.0 DEPENDS config ) It also provides a mechanism to add tests as well. My goal at first would be to update libraries on per-module level(one PR at a time). So to use cmake, the user wold build and install each library individually with cmake. Later, we can update the cmake modules to support superproject building(which may be necessary for libraries that have circular dependencies). Right now, there are no modules for building documentation. This can be added later, as well. So does anyone have any feedback on this setup? If you had ideas, or would like to help update boost libraries, contributions are welcome. Thanks, Paul

6 13

Testing issues
by Belcourt, Kenneth 19 Jan '17

19 Jan '17

Hi, Tests seem to have stopped cycling, and I see this error in the nightly testing output: error: Cannot create link ../../../boost_root/boost/process.hpp to ../../../boost_root/libs/process/include/boost/process.hpp. error: Link previously defined to another file, ../../../boost_root/libs/proccess/include/boost/process.hpp. # Searching for "process_jam_log" in "/scratch/kbelco/boost_testing/boost_regression/stage/bin"... Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 581, in command_regression self.command_setup() File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 352, in command_setup self.build_if_needed(self.process_jam_log,self.pjl_toolset) File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 715, in build_if_needed tool[ 'build_path' ] = self.tool_path( tool ) File "/scratch/kbelco/boost_testing/boost_regression_src/regression.py", line 740, in tool_path , '\n'.join( [ name_or_spec[ 'path' ], build_dir ] ) Exception: Cannot find "process_jam_log" in any of the following locations: Does this problem look familiar to anyone? —- Noel

3 3

[asio] doc format changed?
by Vinnie Falco 19 Jan '17

19 Jan '17

Why did the formatting for Boost.Asio documentation change from 1.61 to 1.63? Compare: http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio.html http://www.boost.org/doc/libs/1_63_0/doc/html/boost_asio.html This looks like it was unintended, and its screwing up search engines (try searching for "Boost Asio 1.63.0 Reference" -- Follow me on Github: https://github.com/vinniefalco

4 9

[Interprocess] move semantics for intrusive_ptr
by Mikolaj Krzewicki 19 Jan '17

19 Jan '17

Dear all, would it be possible to add the rvalue operators to interprocess::intrusive_ptr akin to what is already available in "regular" boost::intrusive_ptr: // Move support #if !defined( BOOST_NO_CXX11_RVALUE_REFERENCES ) intrusive_ptr(intrusive_ptr && rhs) BOOST_NOEXCEPT : px( rhs.px ) { rhs.px = 0; } intrusive_ptr & operator=(intrusive_ptr && rhs) BOOST_NOEXCEPT { this_type( static_cast< intrusive_ptr && >( rhs ) ).swap(*this); return *this; } #endif many thanks, Mikolaj

2 1

[outcome] "sea of noexcept, islands of throwing"
by Andrzej Krzemienski 18 Jan '17

18 Jan '17

Niall, I moved this to another thread, as I believe it is quite independent of the documentation review. I am trying to understand the concept of "sea of noexcept, islands of throwing", and its significance. First, is this programming technique the primary motivation for Boost.Outcome? In the docs, I only saw a small mention of it, but from your replies it looks like this is an important part of the library. But I might be wrong. This "sea and islands" are quite similar to what is described in P0364R0 ("Report on Exception Handling Lite (Disappointment) from SG14"). The authors argue that if the exception control flow is indicated explicitly, the compiler has a better chance of performing optimizations. I understand that your goal (with the Outcome library) is to offer something more modest, but implementable in C++. You are saying, that the C++ compiler can implement similar optimizations, provided that all the try-catch-throw flows are confined to one translation unit. Did I get it right? The authors of P0364R0 claim that in some business domains, like video games, if you encounter a failure to acquire resources, you might as well terminate the program. For this reason RAII is not really that important there: you want to shut down the app rather than clean up and continue. Is it also what you are saying? Do you also intend to support something like 'panic mode' in Rust? I do not know Rust, but I understand that this 'panic mode' is shut down the program but with resource cleanup. Sorry, my questions are quite random. But I am trying to understand the idea. Regards, &rzej;

3 7

Generating Boost documentation with pandoc
by Vinícius dos Santos Oliveira 18 Jan '17

18 Jan '17

Has anyone tried to generate Boost-styled documentation using pandoc? I never fully liked PDF documentation because I never actually print documentation. However, a few weeks ago I got an ebook reader and I've been fascinated by the ePUB format. I'm using it to read even the IETF's RFCs and it's very pleasant. I'm using ePUB to read files even on my usual laptop. Anyway, I was wondering how nice would be to have an ePUB file containing the whole Boost documentation. pandoc has docbook support as one of its input formats and is capable of generating great ePUB output. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[outcome] Added LEWG expected<T, E> implementation, what about the tutorial?
by Niall Douglas 17 Jan '17

17 Jan '17

Quite a bit of feedback from here, from SG14 and from Reddit expressed disappointment that Outcome doesn't implement the LEWG expected<T, E>. basic_monad makes implementing a fully compliant expected<T, E> just a few hours of work, so I went ahead and added one today and you can see its reference docs at https://ned14.github.io/boost.outcome/group__expected.html. These are the known deviations from the LEWG proposal: * P0323R1 doesn't yet specify what will be done if you try accessing an expected which is valueless due to exception. We throw a bad_expected_access<void> in this situation as that seemed sensible. If the LEWG proposal decides on something different, this implementation will change to track the LEWG proposal. * unexpected_type<E> is implemented as an expected<void, E> and it lets the basic_monad machinery do the implicit conversion to some expected<T, E>. * Types T and E cannot be constructible into one another. * expected<T, E> defaults E to error_code_extended. If you don't like this, predefine the BOOST_OUTCOME_EXPECTED_DEFAULT_ERROR_TYPE macro. * The ordering operators are not implemented due to https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/ So now you get in Outcome expected<T, E>; option<T>, result<T> and outcome<T>. And the Expected implementation ought to be drop in compatible with any future C++ 20 standard. How would people prefer the Outcome tutorial to now go? Should it mention expected<T, E> at all? Or should it get its own tutorial page (which will look very similar to the tutorial for result<T>). Which order should they be in? Is expected<T, E> easier than outcomes or the other way round? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

docs for hana broken on webpage (boost 1.63)
by Hans Dembinski 17 Jan '17

17 Jan '17

Hi, the current docs for Hana are still broken: http://www.boost.org/doc/libs/1_63_0/libs/hana/doc/html/index.html yields "404 Not Found". Best regards, Hans

5 8

[function] Problem with simple pointer to function
by Fu ji 17 Jan '17

17 Jan '17

Hello all, I have a problem with boost::function, when I try to assign function to pointer I have a crash. It is simple void function(); boost::function <void (void)> m_Wakeup; and the code where crush occurs looks like: Wakeup = &function; Here is also the dump: Program terminated with signal 6, Aborted. *#0 0x03c4a092 in _dl_start () from /lib/ld-linux.so.2* *#0 0x03c4a092 in _dl_start () from /lib/ld-linux.so.2* *#1 0x03d0eca5 in raise () from /opt/vmware/cimpdk-6.0.0-2768847/debug/build-3825889/lib/libc.so.6* *#2 0x03d104e3 in abort () from /opt/vmware/cimpdk-6.0.0-2768847/debug/build-3825889/lib/libc.so.6* *#3 0x03ca2aec in handleSigSegv () from /opt/vmware/cimpdk-6.0.0-2768847/debug/build-3825889/usr/lib/libsfcBrokerCore.so.0* *#4 0x00310002 in ?? ()* *#5 0x025c060a in move_assign () at /workspace/raid0/src/boost/function/function_template.hpp:998* *#6 swap () at /workspace/raid0/src/boost/function/function_template.hpp:870* *#7 operator=<void (*)()> () at /workspace/raid0/src/boost/function/function_template.hpp:1126* *#8 create_interface () at /workspace/raid0/src/CppWrapper.cpp:298* Do anyone have a clue what was wrong ? Best regards

2 2

Interest in updated expression template library?
by Zach Laine 17 Jan '17

17 Jan '17

I'm trying to gauge interest in submitting a library to the review queue, It's an expression template library called Yap using C++14 and C++17 features, built on top of Hana. It does not work quite the same as Proto, though of course it covers the same problem domain. My goal for the library was to cover the Proto functionality (while allowing the user to write less code than she would have had to with Proto) plus more functionality made easier by the new language features. In the examples you will find nearly all of the Proto examples reproduced, each in a-bit-less to dramatically-less code. The only Proto examples that were left out were ones that are now trivial using Yap due to differences in design. Online docs: https://tzlaine.github.io/yap GiHub page: https://github.com/tzlaine/yap Zach

7 32

BGL Algo Contribution
by Robert R. McCune 17 Jan '17

17 Jan '17

Hello, I'd like to contribute to the Boost Graph Library I've written code for Lexicographic Breadth-First Search (LexBFS) How may I best contribute? Thanks, Ryan

2 1

Re: [boost] Boost 1.64 release date
by Rene Rivera 16 Jan '17

16 Jan '17

On Tue, Jan 10, 2017 at 4:16 AM, Raffi Enficiaud < raffi.enficiaud(a)mines-paris.org> wrote: > Dear all, > > I would like to know in advance (approximately) the release date of 1.64. > > Would it be possible to date of the next release at each new release? > Release Dates Spring release on the second Wednesday of April. Summer release on the second Wednesday of August. Fall/Winter release on the second Wednesday of December. <https://svn.boost.org/trac/boost/wiki/ReleaseSchedule> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 8

[SmartPtr] alternative to enable_shared_from_this
by Roberto Hinz 16 Jan '17

16 Jan '17

Dear Boost Community, I've been following this list for a time with the desire of contributing to Boost. It seems to me a good idea to start with small and easy to review proposals, before attempting anything big. So my first shot is shared_handle class, an alternative to enable_shared_from_this that doesn't suffer from multiple inheritance issues. It also provides the capability of instantiating a shared_ptr to a member object. doc: https://robhz786.github.io/smart_ptr/shared_handle.html source: https://github.com/boostorg/smart_ptr/compare/develop... robhz786:develop Unfortunately, the implementation produces at least one regression: clang 3.1 crashes when it compiles cpp11_pointer_cast_test.cpp with -std=c++11. There may be others since I couldn't test in all compilers used in the regression tests. Nevertheless, is there any interest? Kind regards, Roberto Hinz

9 11

Logging Documentation issue
by jack nade 13 Jan '17

13 Jan '17

There is no visible Design Figure in the Design Overview at http://www.boost.org/doc/libs/1_63_0/libs/log/doc/html/log/design.html using Chrome or IE. The Design Overview refers to it 4 times.

3 3

shutdown ticket-system on svn.boost.org
by Oliver Kowalke 13 Jan '17

13 Jan '17

Hi, I encountered that the ticket system at svn.boost.org is not up-to-date: components coroutine2 and fiber are missing. At least the reports created for coroutine2 and fiber do not know the components (not in drop-down list). I would vote for shutdown of the ticket-system in favour of github - for me it makes no sense to manage two bug reporting systems. best regards, Oliver

9 19

Stringify
by Olaf van der Spek 13 Jan '17

13 Jan '17

On Wed, Jan 11, 2017 at 8:03 PM, Roberto Hinz <robhz786(a)gmail.com> wrote: > On Wed, Jan 11, 2017 at 3:40 PM, Roberto Hinz <robhz786(a)gmail.com> wrote: > > > > > Hi, > > > > I've been working in a format library that contains a function template > > called appendf that can do this: > > > > std::string str("blabla"); > > boost::stringify::appendf(str) () (" AAA ", 25, " BBB ", {255, "x"}); > > assert(str == "blabla AAA 25 BBB ff"); // ( 255 formated in > > hexadecimal ) > > > > This library - I call it Boost.Stringify - is in very early stage of > > development and I though it would be to premature to mention it now. But > > given the repercussion in this thread so far, I changed my mind. So I > will > > soon publish it in github and I will start to write a brief documentation > > so that I can soon present here to gauge interest. > Hi, I think your library deserves it's own thread. ;) How does it compare to for example fmtlib? Gr, Olaf

2 1

gregorian::date limited to years 1400 - 9999
by Viacheslav Usov 12 Jan '17

12 Jan '17

Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999? If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it. I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times. ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense. So my question is, is there any technical problem in supporting the entire 0 - 9999 range? If not, then my next question would be, what else would speak against supporting the 0 - 9999 range? If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400? Cheers, V.

5 7

Tagged pointer library?
by Hans Dembinski 11 Jan '17

11 Jan '17

Hi all, I recently learned about tagged pointers, https://en.m.wikipedia.org/wiki/Tagged_pointer. Over the weekend, I was working on a tiny_string implementation which has a width of only one pointer. Essentially it's a null-terminated char* array managed by std::unique_ptr. On my system, std::string is four times larger (probably 8 byte for the pointer, 8 byte for the length, 8 byte for the allocator and 8 byte for … good measure?). With a tagged pointer, I could even implement a small-string optimisation in that tiny_string, by storing small strings with up to 7 bytes in the memory that otherwise holds the address to the char* array. The tag then allows you to discriminate between the two uses of the memory. You may rightfully question whether it is really practical to do this, but it is certainly one possible application of a tagged pointer. Looking into boost, I found that the lockfree library has a tagged pointer implementation in its "detail" namespace. The implementation is nice, because it falls back to a safe version with a separate tag field on systems which do not follow the required alignment conventions. Wouldn't it make sense to make the tagged pointer accessible by users, i.e. place it in a separate library (or in the existing smart_ptr library)? Best regards, Hans

3 3

tensor library
by Paulo Pereira 09 Jan '17

09 Jan '17

Hello everyone, I am new in the community. I would like to ask, how interesting would be to have in boost a new container with multiple indices (tensor) using variadic templates. I know that Boost.MultiArray library already exists in boost. However I think it does not fulfill the readability and friendliness of something like: newlib::tensor<3,double> t(2,2,3); t(0,0,0)=1; also with extra possibilities similar to Matlab/Octave t(newlib::all,1)=0; I would also like to add mathematical operations t1=t2+t3; using lazy evaluation like in armadillo package or in the David Abrahams and Aleksey Gurtovoy book (C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond). I fell that something similar to this is very important for numerical calculations and somehow it is not a standard in C++ (maybe I am missing something). Best regards, Paulo

4 3

Interested in contributing
by vivekroyandroid＠gmail.com 09 Jan '17

09 Jan '17

Sir, I would like to contribute in whichever way possible. I have a decent amount of knowledge in C/C++, but I am new to contributing to open-source. If someone might guide me and tell me how to proceed, I would appreciate it. Thank You. Vivek Roy --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

Crosscompiling context and fiber without multithreading
by Vitaly Osipov 09 Jan '17

09 Jan '17

Dear all, I am developing for a PowerPC target under real-time os und studying a possibility to employ fibers. They seem to be a good fit, since we have a single thread but several entities, which could in fact be considered parallel. Data exchange through channels also is relevant for the project. The problem is, that though we are provided with a quite recent compiler gcc 4.7.4 with c++11 support, the multithreading part of std is missing, since the OS has its own implementation of multithreading functionality different from pthreads and std::thread. Is there any chance to compile context and fiber without multithreading support? Or it is used under the hood and can not be avoided? Best, Vitaly

2 3

Boost 1.63 vs GCC 5.4.0
by Andrzej Krzemienski 06 Jan '17

06 Jan '17

Hi Everyone, I am trying to determine if Boost 1.63 (or 1.62) will work on GCC 5.4.0 on Linux. I can see in release notes that Boost 1.62 was tested on Linux with "GCC 5.4.1" (I am not aware that v 5.4.1 even exists). However in release notes for 1.63 there is no GCC 5.4 listed for Linux (only for Android). Does anyone know if there is any reason to suspect that Boost 1.63 may have problems on Linux with GCC 5.4.0 ? Regards, &rzej;

4 3

Re: [boost] [root_ptr] Into consideration by Qt & QtQuickCompiler
by Mathias Gaunard 03 Jan '17

03 Jan '17

On 28 Dec 2016 2:32 pm, "Phil Bouchard" <philippeb8(a)gmail.com> wrote: Greetings, I did my homework and the Qt Project is considering root_ptr despite the fact that there is no paper written on it: http://lists.qt-project.org/pipermail/development/2016-December/028222.html So there is a big demand out there. I am not sure what else is required to find a review manager but everything is on a silver plate now. I don't understand how you can possibly interpret that reply as "big demand".

2 3

bad boost_1_63_0.tar.bz2 sha256sum
by jack nade 03 Jan '17

03 Jan '17

Expect beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 for https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.… Get a9eec759dd97798b06eb258a1c6ad4a39ff43b483594a22298ccdfae8116ce16

3 3

[trac] Boost v1.64 in the milestones?
by Raffi Enficiaud 03 Jan '17

03 Jan '17

Dear all, Since 1.63 is (almost) out, would it be possible to have 1.64 in the milestones of trac? Thanks, Raffi

7 15

Review quality (was: [stacktrace] review (changing vote to NO))
by Andrey Semashev 03 Jan '17

03 Jan '17

On Mon, Dec 26, 2016 at 3:58 AM, Vladimir Batov <Vladimir.Batov(a)constrainttec.com> wrote: > On 2016-12-26 10:41, Andrey Semashev wrote: >> >> Acknowledging the need for a particular functionality is not the same >> as accepting a particular implementation. > > Put bluntly users do not care about implementation. Please, don't speak for others. I, personally, very much care about implementation, and I can see other reviewers did take a look at the implementation as well. I think, making judgment on the library quality without regard to the implementation quality is irresponsible and short sighted. That kind of approach tend to result in "5 minute hack" solutions of obviously poor quality. But that's just my opinion. > They care about > functionality provided. I advocate giving the lib a "foot in the door". That > and far better feedback from the users will be a strong incentive for the > author to keep working and improving the lib. You seem to prefer > all-or-nothing approach. I believe it's unrealistic and bad. You might > disagree. First, nowhere in my message I advocated for "all-or-nothing approach". What I advocated for is a fair review, outlining all ups and downs of the library, and if the reviewer feels downs are significant enough, he would be right to vote for rejection. Second, it's not like the library does not exist before it is accepted. Users and the author have every opportunity to try the library in the field, if they want to. There is blincubator.com as well. >> By >> turning a blind eye on a design flaw of a presented library you're >> doing a disservice to the library author and the library users. >> Instead, by giving constructive feedback (positive and negative), >> especially if supported by real world experience, you help the library >> improvement. In fact, this (the feedback) is the most valuable reward >> for the author from the review. And let me say, there's nothing >> humiliating in having a library rejected during a review. > > Well, I do not get scolded often these days. So, it is quite "refreshing" to > learn that I am "turning a blind eye on a design" and "doing a disservice". > I thought I was merely expressing my humble opinion... but probably I got it > all wrong. Well, maybe you shouldn't have taken my message personally then. It wasn't meant to scold anyone. If anything, it was written with the intent to provide another (mine) perspective on what a review is and object to your notion of library review as being a humiliation. The last part, actually, was kind of offending from your side and what triggered my reply in the first place. > As for the feedback, then I do not see voting something useful "no" to be > much of a feedback. Indeed, the author does get initial feedback during a > review. However, not all of that feedback is constructive. Some valid, some > subjective, some capricious. After it's voted out the feedback is no more. The review entails a discussion. Some reviewers get convinced. Some review points get refined, and the author gets convinced. Sometimes review votes get changed. And it's not like the votes are final - the actual decision is taken by the review manager, and he can weigh the points made in reviews and discussion at his discretion. And it's not like the library disappears after the review. If it's interesting and useful, it'll have its users, and they will no doubt provide feedback. > Real valuable feedback will come when the lib is in Boost. People'll start > using the lib (I would) in their real projects asking for this and that. Real world usage produces valuable feedback, no doubt about that. But Boost acceptance is not a pre-requisite for real world usage. >> There are things that can be fixed post-review. >> ... >> There are other things that cannot be fixed easily and would probably >> require changing library design. Those changes often affect library >> API and usage patterns, which warrants the need of a new review of the >> reworked library. > > Yes, all that sounds wonderful... on paper. In real life as a user I'll take > what's available first. Then, if that is improved in the next version, I'll > take it gladly. If design changes and gives me more or fixes something, I'll > accept that. I doubt you'd be so easy to accept the changes if that required you to rewrite half of your code. :) > I do not remember Spirit transitioning from V1 to not > backward-compatible V2 being re-reviewed. I can be wrong though. I don't remember the review either. But Spirit v2 was added in addition to Spirit Classic (aka v1), which is still available in Boost. It was more like a new library was added. Should it have been reviewed? In my opinion, at least a mini-review should have been performed. Luckily, Boost.Spirit dev team has rich experteese in the domain and a lot of experience gained with v1, so v2 was a success. >> In those cases it's better to reject the library so >> that the new, improved version is presented later. > > Again, wonderful.. in theory. The reality IMO is different because 1) > "improving" is better with real user feedback that you deny to the author by > voting "no"; 2) "later" might never come as the review process is quite > exhausting/draining; not everyone wants to experience it again; you might > say "too bad for him"; I'll say it's bad for the user as well as they end up > with your good intentions and no library; 3) "later" might be too late as by > that time the user'll have something else in place. Again, it's not like the library doesn't exist outside Boost. If it fits you, go right ahead, so 1 is not true. But Boost does set a certain bar of quality, and the review process exists precisely to maintain that bar. And I'll take your 2 and 3 any time if it results in a high quality library in Boost. >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. If the accepted library is >> somehow seriously flawed, that flaw may be difficult and painful to >> fix in the future. > > "difficult", "painful", "backward compatibility"... Come on. I am sure > you've been in the industry for a while, have "survived" many > upgrades/updates, etc. We all know it's not an issue. We update, adjust, > move on. Let's just say it can be an issue. On Mon, Dec 26, 2016 at 3:54 AM, Robert Ramey <ramey(a)rrsd.com> wrote: > On 12/25/16 3:41 PM, Andrey Semashev wrote: >> >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. > > How so? Certainly there is no requirement that boost libraries support older > versions of C++ and/or compilers - and indeed many don't. I don't think I > see what you're referring to here. I think you misunderstood. I wasn't speaking of C++ versions backward compatibility. I was speaking of the library backward compatibility. AFAIK, making backward incompatible changes is still considered an undesirable practice. >> If the accepted library is somehow seriously flawed, > > Then of course it should be rejected. Of course reaching a concensus as to > whether it's flawed might not be so easy. Right, that was my point. >> [1]: http://www.boost.org/community/reviews.html > > I checked this page and don't see where it says anything relevent to your > points. Maybe you missed this section: http://www.boost.org/community/reviews.html#Comments <quote> Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. The goal of a Boost library review is to improve the library through constructive criticism, and at the end a decision must be made: is the library good enough at this point to accept into Boost? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time. The Serialization library is a good example of how constructive criticism resulted in revisions resulting in an excellent library that was accepted in its second review. </quote>

8 16

[sandia] Sandia-intel-16.0-c++11 is running in C++14 mode
by Andrey Semashev 02 Jan '17

02 Jan '17

Hi, Despite what the name implies, Sandia-intel-16.0-c++11 is actually running in C++14 mode. You can see there is -std=c++14 in the compiler command line: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Could this inconsistency be fixed?

2 1

[Stacktrace] Review Manager report
by Niall Douglas 02 Jan '17

02 Jan '17

Firstly happy new year to everyone, and many thanks to all those who participated in the peer review of proposed Boost.Stacktrace before Christmas. I received the following formal reviews: 1. Vladimir Batov (YES) 2. Klemens Morgenstern (YES) 3. Andrey Semashev (NO) 4. Nat Goodspeed (YES) 5. Artyom Beilis (NO) 6. Barrett Adair (YES) Extensive comments without a formal acceptance recommendation were also made by: 1. Peter Dimov 2. Edward Diener There was a very noticeable lack of consensus on the strengths and weaknesses of the proposed library which has made summarising all these reviews into a coherent report with concrete conditions for acceptance very difficult. Antony also responded to many of the concerns throughout the review, agreeing with some points, disagreeing with others. I think this lack of consensus stemmed from multiple opinions on what a stacktrace library ought to provide: Minimum viable product: A portable backtrace() and backtrace_symbols() implementation with a C++ STL idiomatic API. The stack backtrace capture implementation must not allocate memory and be "fast". Note that backtrace_symbols() does NOT symbolise into strings containing source file name and line number. It also allocates memory (backtrace_symbols_fd() does not). Opinion 1: Portable serialisation of the stacktrace with instruction pointers converted to offsets into SO/DLL binary paths so a later external process can use those in combination with their debug symbols to retrieve source file names and line numbers. Ideally the serialisation formats supported would include those consumable by well known tooling for this purpose e.g. addr2line or llvm-symbolizer. Opinion 2: That Stacktrace can in process use debug symbols to retrieve source file names and line numbers. This could be implemented by invoking addr2line or equivalent as a child process which has the enormous advantage of being async safe, but has disadvantages in almost every other area. Or it could be implemented by one's own DWARF parser but with the huge caveat that memory could be badly corrupted by now. Opinion 3: That Stacktrace be "async safe" in that backtraces can be safely captured and parsed from a signal handler or SEH/TEH handler callback or point of C++ exception throw. *This implies no memory allocation during the execution of the handler*. >From the reviews, I think there is consensus that the minimum viable product is achieved in Stacktrace though many mentioned that improvements are needed to the documentation and most of the negative feedback was on features not in the minimum viable product described above. I therefore recommend the ACCEPTANCE of proposed Boost.Stacktrace into Boost with the following conditions: 1. That the documentation more clearly set out what Stacktrace does and especially does not do, and that the default facilities provided are those of the Minimum Viable Product described above i.e. no source file nor line number discovery, no external dependencies on libraries not always provided on the target platform, no invocation of child processes, no async safety during stacktrace parsing. Stacktrace ought to be pared back to the minimum viable product featureset with no external dependencies at all. 2. That suitable predefined macros opt in to additional functionality such as serialisation of offset translated backtraces, retrieval of source code path and line number etc. Enabling these may introduce dependencies on third party libraries not always present on a system such as libunwind, or on third party helper utilities such as addr2line. I would recommend that the APIs the use of which are dependent on such third party items are entirely compiled out of Stacktrace when the macro enabling them is not defined. 3. That the documentation describe ONLY the default minimum viable product functionality in its tutorial and quick start. All extra functionality enabled by macros is to be relocated into a separate documentation section away from the main documentation e.g. "Advanced/optional features". 4. That APIs made available only when a given macro has turned them on are documented as such in the API reference docs. I'd like to congratulate Antony on getting yet another library of his into Boost. I hope some of his magic rubs off on me when I bring Outcome to review later this year! Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 3

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 02 Jan '17

02 Jan '17

Hello Daniel, I'm referring to http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/fiber/performance.… . The page should contain three tables (the one related to threads is missing) - my modification s date from end of November. Oliver Am 27.12.2016 1:35 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 08:59, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hi, > could you update the documentation of boost-1.63 please - it is not up to > date. > For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed76 5ee0cd40d2 > (17.12.2016) is missing. > Thank you in advance, > Oliver The documentation on the website should just be whatever is in the release. It's a bit hard to know without a link to the page where that change is meant to be. I think what you're seeing on the website are the html files that are checked into git. I guess the documentation build isn't replacing them. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

3 4

Re: [boost] [Bulk] Voronoi
by ayse 30 Dec '16

30 Dec '16

Thank you, I will watch it. Belowing code gives "floating point divide by zero" error std::vector<Segment>segments; segments.push_back(Segment(40, 0, 40, 100)); segments.push_back(Segment(40, 0, 100, 0)); segments.push_back(Segment(40, 100, 100, 100)); segments.push_back(Segment(100, 0, 100, 30)); segments.push_back(Segment(70, 30, 100, 30)); segments.push_back(Segment(70, 30, 70, 70)); segments.push_back(Segment(70, 70, 100, 70)); segments.push_back(Segment(100, 70, 100, 100)); // Construction of the Voronoi Diagram. voronoi_diagram<double>vd; * construct_voronoi(segments.begin(), segments.end(), &vd); // it gives floating point divide by zero error* My drawing, [image: Inline image 2]

1 1

[sandia] Intel compiler testers fail
by Andrey Semashev 29 Dec '16

29 Dec '16

Hi, Most of the Sandia-intel-* testers currently fail with the error saying /tmp is full. See here, for example: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Could this be fixed? Thanks.

2 1

Voronoi
by ayse 29 Dec '16

29 Dec '16

Hi, Is boost-voronoi able to calculate voronoi diagram of closed polygons, if yes how? When I insert segments connected , it gives "floating point dividing by zero" error. Any help would be appreciated. Best regards, Ayşe.

3 2

Boost 1.63.0 is released!
by Marshall Clow 29 Dec '16

29 Dec '16

Release 1.63.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1.63.0 You can also download directly from SourceForge: https://sourceforge.net/projects/boost/files/boost/1.63.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks to everyone who participated in this release. Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

4 3

Re: [boost] Variadic append for std::string
by Nat Goodspeed 29 Dec '16

29 Dec '16

On Dec 28, 2016 7:20 PM, "Yakov Galka" <ybungalobill(a)gmail.com> wrote: On Tue, Dec 27, 2016 at 4:47 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > One frequently needs to append stuff to strings, but the standard way > (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries. > Can't we already write it through (((s += "A") += "B") += to_string(42))? This is the time I think that assignment operators, other than =, should have had left associativitiy... pity they don't. I think what's desired here is a two-pass approach in which append() or concat() or whatever first figures out the final length required, allocates that much storage, then appends into it with no further expansion. When we say it should understand two kinds of string_view, etc., I assume that the catch-all case for each arg would be "anything that can be treated as a range of char_type."

2 1

[conversion] Release build error..
by Rene Rivera 29 Dec '16

29 Dec '16

Please fix this ASAP: error: Unable to find file or target named error: 'conversion' error: referred to from project at error: '/home/ubuntu/boost/libs/conversion/doc' Failed: 'b2' '--debug-configuration' '-j2' '-q' '-d0' '--build-dir=/home/ubuntu/build' '--distdir=/home/ubuntu/build/dist' '--release-build' 'auto-index=off' ERROR = 1 -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[root_ptr] Into consideration by Qt & QtQuickCompiler
by Phil Bouchard 28 Dec '16

28 Dec '16

Greetings, I did my homework and the Qt Project is considering root_ptr despite the fact that there is no paper written on it: http://lists.qt-project.org/pipermail/development/2016-December/028222.html So there is a big demand out there. I am not sure what else is required to find a review manager but everything is on a silver plate now. Sincerely, -Phil

1 0

[Beast] Implementing the Asio deallocation guarantees
by Vinnie Falco 27 Dec '16

27 Dec '16

A user wrote up this detailed bug report on Beast. The problem is that Beast does not guarantee that all temporary memory allocations will be freed before the handler is invoked during the upcall. I'd like to fix it, but all the fixes are quite ugly. I am wondering if anyone has any experience, suggestions, or advice to add to the conversation before I try to pick the least distasteful option: https://github.com/vinniefalco/Beast/issues/215 Thanks

1 0

Merging superproject fb83378 to master
by Peter Dimov 27 Dec '16

27 Dec '16

Can we please merge https://github.com/boostorg/boost/commit/fb8338770e930bca5ba24dbb9240f5c2e4… to master? Without it, Boost.Build requires the tools/inspect submodule to be present, which is otherwise unnecessary in partial Travis checkouts.

1 1

documentation 1.63 not up to date
by Oliver Kowalke 27 Dec '16

27 Dec '16

Hi, could you update the documentation of boost-1.63 please - it is not up to date. For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed765ee0cd40d2 (17.12.2016) is missing. Thank you in advance, Oliver

3 4

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 27 Dec '16

27 Dec '16

OK, thank you - I'll test your suggestions. Am 27.12.2016 2:12 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 12:45, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hello Daniel, > I'm referring to > http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/ fiber/performance.html > . > The page should contain three tables (the one related to threads is > missing) - my modification s date from end of November. > Oliver The change you referred to before was from the 17th, but the html file in git was last updated on the 10th. https://github.com/boostorg/fiber/blob/master/doc/html/ fiber/performance.html I guess that's what you're seeing. I'm not sure how the build is set up now, but I'm guessing it wasn't set up to build the fiber documentation because there's already html files there. To build the documentation, I think you need to change the end of your documentation jamfile to something like: alias boostdoc ; explicit boostdoc ; alias boostrelease : fiber ; explicit boostrelease ; Although, I can't test that now, so it might be wrong. I'd also delete the html documentation from the repo, as a broken link is a better indicator that the documentation isn't being built. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

1 0

Boost Fiber & ASIO CPU spinning
by Daniel Larimer 27 Dec '16

27 Dec '16

I am attempting to combine Boost Fiber with Boost ASIO and am having very poor results. Code: int main() { boost::asio::io_service io; boost::fibers::use_scheduling_algorithm< boost::fibers::asio::round_robin > ( io ); io.run(); return 0; } This code should startup and then sleep, but instead it pegs the CPU at 100%. The code I used for boost::fibers::asio::round_robin can be found here: http://www.boost.org/doc/libs/1_62_0/libs/fiber/examples/asio/round_robin.h… When I inspect the round_robin scheduler it appears to be switching back and forth between two different fibers. If I put a print statement inside asio_rr_service_lambda then it constantly reports that it has ready fibers. I'm looking for a working example. Dan

2 1

PHP error in string_ref docs
by Olaf van der Spek 27 Dec '16

27 Dec '16

Hi, Got a PHP error in the docs.. http://www.boost.org/doc/libs/master/libs/utility/doc/html/string_ref.html /home/www/live.boost.org/common/code/boost.php:16: htmlentities(): Invalid multibyte sequence in argument -- Olaf

2 3

Re: [boost] [stacktrace] review (changing vote to NO)
by Artyom Beilis 26 Dec '16

26 Dec '16

> > 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding > > the use of the library. > > Those flags are not required because addr2line can extract information > from debug sections of the binary. Yes.. this is exactly the issue - I don't think that addr2line should be used by default. Getting the stack trace using dladdr works very well - so no need to use add2line unless absolutely required. I also want to hear regarding inefficiency of add2line use - creating the process for each stack frame you wanted to trace. It is very inefficient so I suggest not to use one. Finally reviewing your code once again I realized following: 1. Instead of using adde2line to get the object name you can just call add2line with /proc/12345/exe (works with dynamically loaded shared objects as well - i tested it) 2. Use of addr2line for every each frame must be fixed But what is most important that I understood that you don't even use dladdr to get function names even if you can - which is very bad decision. Additionally I realized that with_trace and traced aren't parts of the library! These should be built in there by default. -------------------------- After using the library and running couple of tests on Linux with GCC.. I have to revoke my "Conditional YES" vote and change it to "NO": And the reason is following: 1. Linux/*nix backend is poor - instead of using dladdr to get function names easily as I do in the backend I written and use on CppCMS [1] you call external exe in very inefficient way. 2. I realized that the library does not provide the basic functionality like collecting strack trace on throw (what I thought was built in but I was mistaken) 3. No answer for non MSVC compilers built in. But the most important reason that the library does not feel mature enough in terms of both backends and frontends. I strongly strongly strongly recommend to continue the work on the library as it provides important functionality. The frontend should be adjusted a little to couple with common cases. The backend must be modified to not to fork/exec by default and optimize one significantly. I clearly understand you to want to use addr2line as it gives more power but it can't be used by default. I searched for a long time for a lightweight solution for converting addresses to the function names for CppCMS including trying to use debug information but couldn't find anything suitable besides dlfunc. However addr2line is by no means can be accepted as "default" solution. I also recommend to take a look on cppcms's backtrace library it is very simple and provides critical information in production environment. Regards, Artyom Beilis [1] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/lib… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

6 11

[root_ptr] Potential support from Qt & QtQuickCompiler
by Phil Bouchard 25 Dec '16

25 Dec '16

Greetings, As you know the WebKit project has a very complex memory manager that cannot be swapped easily but The Qt Project might be interested for a faster alternative than the garbage collector: http://lists.qt-project.org/pipermail/development/2016-December/028199.html This is just a head's up in case anybody is interested into the subject and is aware of Qt. I know by experience garbage collectors will always let you down for complex projects so I think there is no other solution. Thanks & Merry Christmas, -Phil

1 0

Boost 1.63.0 Release Candidate 2
by Marshall Clow 25 Dec '16

25 Dec '16

The second release candidate for the 1.63.0 release is now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The only changes are in Boost.Config, Boost.Context, and Boost.Fiber. The SHA256 checksums are as follows: 25db3956a8d58187ac7a0702cc917e9bab47ff90baafc35e4e789dca1ce5f423 boost_1_63_0_rc2.7z beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 boost_1_63_0_rc2.tar.bz2 fe34a4e119798e10b8cc9e565b3b0284e9fd3977ec8a1b19586ad1dec397088b boost_1_63_0_rc2.tar.gz 97ce6635df1f44653a597343cd5757bb8b6b992beb3720f5fc761e3644bcbe7b boost_1_63_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

5 6

Re: [boost] Boost 1.63.0 Release Candidate 2
by Stephan T. Lavavej 24 Dec '16

24 Dec '16

[Marshall Clow] > The second release candidate for the 1.63.0 release is now available at: > https://sourceforge.net/projects/boost/files/boost/1.63.0/ > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. 1.63.0 RC2 successfully built for mingw-w64, without any workarounds. (Boost.Fiber is detecting my lack of std::mutex and simply not building, which is fine by me.) Notably, this is the first time that I've ever been able to build Boost without patches or workarounds. This is after bootstrap.sh was fixed for mingw-w64/msys2, Context/Coroutine/Coroutine2 were fixed to build for mingw-w64, and Python auto-detection started working again. Yay! Thanks, STL

2 1

Stacktrace review: concern, probable solution and review news
by Antony Polukhin 23 Dec '16

23 Dec '16

Hi, The biggest concern with the stacktrace library is it's usability in async-signal-handlers. Here are some facts: * users definitely want to use the library in async-signal-handlers to print stacktraces on SIGSEGV/SIGBUS/SIGABRT * the only cross-platform async-signal-safe thing that can be done - is to print function addresses (without names and source line locations) * reviewers wish to have a smaller size of the `stacktrace` class, want to avoid template parameter and have a std::vector<frames> like interface (this is async unsafe because vector does dynamic allocations). So, the solution: * Change `basic_stacktrace<size_t>` to `basic_stacktrace<class Allocator = std::allocator<void*>>` and make it's constructor async-unsafe and add additional runtime parameter for stack depth. * Provide async-safe functions that dump addresses separated by whitespace (format also acceptable by addr2line and atos): * `void dump_stacktrace(int fd)` * `void dump_stacktrace(HANDLE fd)` * `void dump_stacktrace(const char* filename)` * Provide an example with dumping callstack to a file and printing it on program restart Does it seem reasonable? Does it satisfy your needs? Review news: * User named LogicalKnight tested the library on MacOS and it works well. A few issues in examples must be fixed: https://github.com/apolukhin/stacktrace/issues/10 My list of TODOs for the library: * Fix the async unsafe code in signal catching example * ? Provide a low-level API for getting stacktrace as array of void pointers * MinGW fails to compile, because of missing "Dbgeng.h" headers. This must be fixed by manyally forward declaring required functions using the boost.winapi way. * Add a note about the Boost.Exception usage to the example with embedding stack into exception. * Take a look at the llvm-symbolizer, atos and libdwraf; try hard to produce a non-forking solution * ? Deserialization/inspection of stacktrace on other machine * BOOST_NOINLINE inline trick to avoid printing internals in the stacktrace + fix Intel warnings * At github one of the users was complaining about the performance of ostreaming operations. There is a way to significantly speedup ostreaming without changing the interface of the library. I'll do the optimization after the Boost Review. * Improve docs for the "Build, Macros and Backends" sections (say that library is using system headers, no 3rd party libraries must be installed or manually linked; backtrace() is LINUX specific, not POSIX) * Add a note to the docs that library is header only by default and usable in C++98/C++03. Things NOT to do ever: * Integration with BOOST_THROW_EXCEPTION and Boost.Exception - those ideas are out of the library scope * Callbacks to do things on stacktraces - no way to satisfy all the needs and make them optimal on all the platforms. Do some caching instead -- Best regards, Antony Polukhin

5 11

Re: [boost] [Stacktrace] review
by Barrett Adair 23 Dec '16

23 Dec '16

On Wed, Dec 14, 2016 at 2:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > The formal review of the Stacktrace library by Antony Polukhin starts > today 14th Dec and will conclude before Christmas. I appreciate we > are likely a bit tired out from the many library reviews recently and > of course it's Christmas, but given the lack of a portable way to > work with stack backtraces, which you inevitably need to do > eventually in any non-toy production application, Stacktrace needs > your review! > > For your review you may wish to consider the following questions: > > What is your evaluation of the design? I like it. > What is your evaluation of the implementation? I've never implemented a stacktrace reader, so I don't have much to add. The code did not raise any red flags for me, though. > What is your evaluation of the documentation? Documentation is solid. > What is your evaluation of the potential usefulness of the library? Very useful. I will likely use this at work. > Did you try to use the library? With what compiler? Did you have any problems? Yes, GCC 5.3, no problems. This stacktrace made me smile: 0# boost::stacktrace::detail::backend::backend(void**, unsigned long) 1# s::~s() 2# void __gnu_cxx::new_allocator<s>::destroy<s>(s*) 3# void std::allocator_traits<std::allocator<s> >::destroy<s>(std::allocator<s>&, s*) 4# std::_Sp_counted_ptr_inplace<s, std::allocator<s>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() 5# std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() 6# std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() 7# std::__shared_ptr<s, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() 8# std::shared_ptr<s>::~shared_ptr() 9# hello()::{lambda()#1}::~hello() 10# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_destroy(std::_Any_data&, std::integral_constant<bool, false>) 11# std::_Function_base::_Base_manager<hello()::{lambda()#1}>::_M_manager(std::_Any_data&, std::_Function_base::_Base_manager<hello()::{lambda()#1}> const&, std::_Manager_operation) 12# std::_Function_base::~_Function_base() 13# std::function<void ()>::~function() 14# void std::_Destroy<std::function<void ()> >(std::function<void ()>*) 15# void std::_Destroy_aux<false>::__destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 16# void std::_Destroy<std::function<void ()>*>(std::function<void ()>*, std::function<void ()>*) 17# void std::_Destroy<std::function<void ()>*, std::function<void ()> >(std::function<void ()>*, std::function<void ()>*, std::allocator<std::function<void ()> >&) 18# std::vector<std::function<void ()>, std::allocator<std::function<void ()> > >::~vector() 19# hello() 20# main 21# __libc_start_main 22# _start > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 45 minutes total. I skimmed the code, the documentation, and the test cases. Then, I made a little test program. > Are you knowledgeable about the problem domain? No. > Do you think the library should be accepted as a Boost library? Yes, unequivocally. The concerns about async safety are interesting, but ultimately this library is useful to me (and likely many others) regardless of signal support. Barrett

1 0

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Remi Chateauneu 22 Dec '16

22 Dec '16

Maybe the RDTSC instruction might help for x86 processors, as it returns a number of ticks which is reset at startup. It is also extremely fast. Le 22 déc. 2016 13:04, "Thomas Dahms" <thomas.dahms(a)native-instruments.de> a écrit : Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

2 1

[interprocess] Getting boot-up time is unreliable on Windows
by Thomas Dahms 22 Dec '16

22 Dec '16

Dear developers, dear Ion, We are experiencing issues on Windows where boost::interprocess relies on a certain event in the system event log to get the system's boot-up time. This has proven to be unreliable, because that event is not always present in the log. In that case, initialization of boost::interprocess fails. Several bug reports exist for that issue, e.g. [1, 2]. Report [1] contains a proposed fix to use GetTickCount64() and there is an open PR with an alternative fix to fall back to WMI mechanisms [3]. I understand that the fix [1] would need some polishing, because GetTickCount64() is not available in pre-Vista. Nevertheless, both proposed fixes have been uncommented and unconsidered for a while now. Is there any chance that the maintainers could look into this? Thank you! Regards, Thomas [1] https://svn.boost.org/trac/boost/ticket/12137 [2] https://svn.boost.org/trac/boost/ticket/12232 [3] https://github.com/boostorg/interprocess/pull/18 -- Thomas Dahms Software Developer Native Instruments GmbH www.native-instruments.com

1 0

Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

The release candidates for the 1.63.0 release are now available at: https://sourceforge.net/projects/boost/files/boost/1.63.0/ The SHA256 checksums are as follows: 010699561c6011e6d97dc453d55bc5e54cdc192622434eff7b8ac559efac846c boost_1_63_0_rc1.7z d8ebf8d90b2f823f04119445ac339d704395d655907333ec0fab863040119d24 boost_1_63_0_rc1.tar.bz2 dabe29b8a60369ae7c15c20681a32717f3c37d97e5dc6d39c5b2fd0494b8e995 boost_1_63_0_rc1.tar.gz 1683942022fd63c205c48fb2155af6094c67ef67aa13ffb3e1db78fecf817efe boost_1_63_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The release managers

12 25

Please update Track config
by Antony Polukhin 21 Dec '16

21 Dec '16

Hi, Please, change the default owner for variant issues from ebf to apolukhin (it's me, I'm taking care of the library for last few years). This change will help me to react faster on variant issues. Also, please add the dll component into the list of components so that people could properly report Boost.DLL issues https://github.com/boostorg/dll. Make me (apolukhin) the default responsible for the issues. Thanks in advance! -- Best regards, Antony Polukhin

1 0

Re: [boost] [Boost] [Stacktrace] review
by Nat Goodspeed 21 Dec '16

21 Dec '16

On Wed, Dec 14, 2016 at 3:43 AM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > I'm generally pleased with the design. There's a documentation section "Exceptions with stacktrace" that discusses techniques for incorporating stacktrace data into your own exceptions. I see a real possibility for integration with Boost.Exception, perhaps even a mechanism to make BOOST_THROW_EXCEPTION embed the stacktrace at the throw point. This is not an objection to accepting the library, but rather a feature request for when we do. I do have a question about use of a template parameter to constrain the number of entries, rather than a runtime parameter. Presumably that's necessary to permit certain backend implementations to be async-signal-safe? (Whatever the rationale, a note in the documentation explaining it would be nice.) My objection to that is that apparently, with the present design, if I want to write a function that accepts any specialization of basic_stacktrace, that must itself be a template function. If I'm correct about the reason for using a template parameter, would it be reasonable to split the class into a non-template base class supporting all the methods, with a template subclass that provides the storage? The base class could store a (pointer, length) passed by the subclass constructor. Without having looked at the implementation, I expect that you wouldn't even need virtual-function dispatch: the only indirection would be through the data buffer pointer. That would even permit a subclass that provides dynamic storage, for async-signal-unsafe use. Then a processing function could accept reference-to-base-class and handle any stacktrace instance. > - What is your evaluation of the implementation? Sorry, I haven't looked at the implementation. > - What is your evaluation of the documentation? > Generally good. It could stand a cleanup pass; there are a few typos here and there. I do like that each method explicitly states both complexity and async signal safety. The description of the nullary frame() constructor says that source_line() will return both empty string and 0. > - What is your evaluation of the potential usefulness of the > library? > VERY! I want this. > - Did you try to use the library? With what compiler? Did you > have any problems? > No, I haven't tried to use it. (A deadline is coming up fast.) > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I read through the documentation. > - Are you knowledgeable about the problem domain? > I have occasionally used platform-specific tactics to try to achieve the same thing, on a couple different platforms. Each time it's been painful enough to make me wish that this problem were solved, once and for all. > And finally, every review should attempt to answer this question: > > - Do you think the library should be accepted as a Boost > library? > Yes I do. I would like to see the non-template base class, but that's not a showstopper: I would rather have this library without than not have it at all. As I mentioned, I would like to see integration with Boost.Exception. That just seems like a natural next step. I see further opportunities for integration with Boost.Context, Boost.Fiber...

11 121

Stacktrace library starts review today 14th Dec
by Niall Douglas 21 Dec '16

21 Dec '16

The formal review of the Stacktrace library by Antony Polukhin starts today 14th Dec and will conclude before Christmas. I appreciate we are likely a bit tired out from the many library reviews recently and of course it's Christmas, but given the lack of a portable way to work with stack backtraces, which you inevitably need to do eventually in any non-toy production application, Stacktrace needs your review! Stacktrace is an optionally header-only library providing four implementation backends, libunwind (POSIX only), windbg (Windows only), backtrace (from the C library on most POSIX implementations) and a null backend. At its very simplest it lets you capture the stack backtrace for the calling thread and to print it to a std::ostream& of your choice. The basic_stacktrace<> class quacks like a STL container of frame object instances. The rest of the API pretty much follows STL design principles for the most part. Use is therefore unsurprising. You can find the documentation at http://apolukhin.github.io/stacktrace/index.html and the github repo at https://github.com/apolukhin/stacktrace. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[stacktrace]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 's_sourceforge at nedprod dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? Most of my personal concerns with this library are with the implementation and I would hugely appreciate feedback from others with substantial experience of using stacktracing "in anger" in non-trivial use case scenarios. - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. Finally, thanks to Edward whose announcement of the Synapse library review I borrowed heavily from as I thought it very well structured. Hopefully the above is just as clear. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 21

Re: [boost] [EXTERNAL] Boost 1.63.0 Release Candidate 1
by Marshall Clow 21 Dec '16

21 Dec '16

On Tue, Dec 20, 2016 at 2:51 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > On Tue, Dec 20, 2016 at 12:49 PM, Rene Rivera <grafikrobot(a)gmail.com> > wrote: > >> >> >>>>>> >> >>>>>> As I mentioned to Marshall, the results here: >> >>>>> http://www.boost.org/development/tests/develop/developer/ >> config.html >> >>>>> are >> >>>>> horribly outdated - are they actually being run and updated? >> >>>>> >> >>>>> >> >>>> It appears that all 'develop' tests are at least one week late if not >> >>>> much >> >>>> more. >> >>>> >> >>> >> >>> >> >>> I was not aware of the stalled results.. Investigating now. >> >>> >> >> >> >> I think Sandia testers on Darwin and Linux are cycling okay in both >> >> develop and master, there’s results up there from Dec 20th. Are the >> Sandia >> >> config test results wrong or unexpected? >> >> >> > >> > The latest results from Sandia that I can see are from 12th. The report >> > info[1] also says it was run last time on 12th. >> > >> > [1]: http://www.boost.org/development/tests/develop/developer/ >> index.html >> >> >> The report generation issue is now addressed. The results are current and >> show tests from today. >> >> > I see lots of new results for "master", but none for "develop". (yet) > > Interesting. This page: http://www.boost.org/development/tests/develop/developer/config.html shows new results, but this one http://www.boost.org/development/tests/develop/developer/summary.html does not. -- Marshall

3 3

[test] Really deactivate test
by Florian Lindner 19 Dec '16

19 Dec '16

Hello, I need to conditionally decativate tests and use a custom decorator for that, like that: virtual void apply(bt::test_unit& tu) { [...] if (std::find(_ranks.begin(), _ranks.end(), rank) == _ranks.end()) { std::cout << rank << " Disable, because of rank, test: " << tu.full_name() << std::endl; tu.p_default_status.value = bt::test_unit::RS_DISABLED; return; } } (i'm happy to provide full source code, if anyone is interested) As you can see it's deativated on some MPI ranks only. However, if a user uses -t "testname" it is activated again. Is there a way to really deactivate the test? Or delete it from the test tree? Thanks, Florian

2 5

[variant] gcc crash
by Igor R 18 Dec '16

18 Dec '16

Consider the following snippet (trying to compile with Boost 1.62): ///////////////////////////////////////////////////////////// #include <boost/variant.hpp> template<class Node> struct node1_type; struct var_type; using var_base = boost::variant<int, boost::recursive_wrapper<node1_type<var_type>> >; template<class Node> struct node1_type { Node child; }; struct var_type : var_base { using var_base::var_base; }; int main() { var_type v1 = 1; } /////////////////////////////////////////////////////////////////// It crashes GCC: http://melpon.org/wandbox/permlink/A6BuYqqrG4COcfFl and produces compilation error with any released version of Clang: http://melpon.org/wandbox/permlink/1JQ7OVLV3crERRJX (Although it does compile with Clang-4 trunk). I'd appreciate if Variant maintainers could take a look at it. Thanks.

3 2

Re: [boost] [Boost-users] Stacktrace library starts review today 14th Dec
by Antony Polukhin 18 Dec '16

18 Dec '16

2016-12-15 3:44 GMT+03:00 Edward Diener <eldiener(a)tropicsoft.com>: > In the documentation for stacktrace I do not see anything about what level > of C++ is required for a compiler using the stacktrace library or any > information on what compilers have been tested when using the library. It's C++98. Tested on latest clang(c++03, c++11), gcc(c++98, c++11, c++1y), msvc. > In the section of "Build, Macros and Backends" I do not think there is > enough information about using a particular backend, other than saying that > you need to link with such-and-such. Does stacktrace "automatically" find > the header files it needs from these backends ? Even so I think some > information about where it looks for the backend header files need to be > given. I also think that some information of what libraries it looks to link > with needs to be given. I am assuming it links with the static versions of > these backend libraries unless I define either BOOST_STACKTRACE_LINK and > BOOST_ALL_DYN_LINK, or BOOST_STACKTRACE_DYN_LINK. What if I want to use the > header-only version but I want to link with the shared library backend ? I > also assume that if I link with the static library backend I should probably > be linking with the RTL static library, while if I link with the shared > library backend I should also be linking with the RTL shared library. > > What about 32-bit versus 64-bit use of stacktrace ? Do they both work as > advertised with the correct backends, whether static or shared ? I think the > "Build, Macros and Backends" need rto be expanded to cover alol these > topics. All the headers are found automatically and the library is header only if you do not define BOOST_STACKTRACE_LINK or BOOST_STACKTRACE_DYN_LINK. Backend is chosen automatically in header only mode. You need to do nothing, unless you encounter some problems on default setup (like you OS is POSIX but not LSB Core Specification 4.1) or unless you wish to disable stacktraces. If you define BOOST_STACKTRACE_LINK or BOOST_STACKTRACE_DYN_LINK you have to manually link with one of the backends. I'll try to improve the "Build, Macros and Backends" section to be more clear. -- Best regards, Antony Polukhin

3 3

[iterator][type_traits] A test is failing with gcc in c++03 mode
by Edward Diener 17 Dec '16

17 Dec '16

The zip_iterator_test_std_pair is failing with gcc in c++-03 mode. The problem reduces viqa Boost type traits to the fact that in gcc c++03 mode the expression: __is_abstract(std::pair<int&, std::string&>) where __is_abstract is a compiler intrinsic, gives an error of: error: forming reference to reference type 'std::__cxx11::basic_string<char>&' pair(const _T1& __a, const _T2& __b) ^~~~ Is this a valid error according to the C++ 2003 standard ? The test works in c++11 or c++14 mode.

4 8

Synapse library review result
by Edward Diener 14 Dec '16

14 Dec '16

The Decision --- -------- There were a total of 9 people, outside of the library author Emil Dotchevski, who reviewed/commented about the Synapse library during the review period and the Monday following where I accepted a late review and people's responses to that late review. The voting in the Synapse review is: 0 for YES 2 for NO, with one of the two a provisional NO. Among the other people who commented but did not vote I have 2 people who said they definitely liked the library and 2 people who said they definitely did not like the library. Among other commenters I interpreted 2 other people as probably approving of the library as it now is and 1 other person as probably not approving of the library as it now is. Given the actual YES or NO vote, and the small amount of people who took part in the review, and the even smaller amount of people who decided to vote YES or NO for the library, the Synapse library is NOT accepted into Boost. My decision as review manager is based on the review of the library by others and not on my own personal view of whether the library should be accepted or not. Issues ------ I want to use the next part of this decision to summarize the issues brought up largely, but not exclusively, by those who did not see the Synapse library as currently being worthwhile to become a part of Boost. This issues I summarize below may or may not be seen as relevant or not by others but they do represent the areas of criticism of the library made during the review. All the issues were answered by Emil during the review, and I think he did an excellent job of answering reviewers based on how he sees these issues. Some of these issues may be seen as unimportant or trivial or already well answered, but I want to list them all nonetheless. The issues are presented in no particular order of importance. I will refrain from making my own comments about these issues until my own general summary at the end of this review decision: 1) The current Boost signals/signals2 library is adequate for signal/slot processing and another signal/slot library such as Synapse does not provide enough of a usage argument to be added to Boost along with what already exists. 2) The documentation needs to be more expansive on the difference between Boost signals/signals2 and the Synapse library. 3) The end-user should have some sort of control where Synapse stores its information regarding the connection between signal emitters and slots ( signals handlers ). 4) Since Synapse is a C++11 library it should use C++11 standard library constructs across the board rather than their Boost equivalents. 5) There should be some "natural" way in which slots can return a value, ala the signals2 library. 6) A more flexible way of handling the slot lifetimes should be created as an addition to the shared_ptr/weak_ptr way the library currently employs. 7) A means by which a particular thread can be specified ( thread-affinity ) for a particular slot when connected should be created; or a dispatching mechanism, perhaps using asio, for connecting a slot to an emitter. 8) The ability to have signals emitted with more than four parameters should be created. 9) The fact that emitters are identified strictly by address was seen as a weakness in the design since at least theoretically, if not very often practically, it is possible for two different variables to have the same address. Connected to this is that the address of emitters is noted with a "void *" in the public interface, and that was criticized as not C++-like. 10) Connection objects should be movable rather than using shared_ptr. 11) The central dispatching mechanism is too slow for large scale continuous changes which emit signals to be handled by slots in some systems ( a stock market changes type of application was brought up as such an example ). 12) The use of only Boost function as a callable slot is too inflexible. 13) The signal type ( pointer to function whose return type identifies signals ) was seen both as cryptic and inflexible, and a deduced signal type was suggested. 14) Having more than one signal type in Boost in general was seen as a bad situation. 15) More specific information on which compilers should work with Synapse. Summary ------- First of all, thanks to everyone who participated in the review and for Emil for answering and providing explanations for his design and coding decisions. I cannot say it enough but I really hope that more people can be encouraged to look at libraries up for review and make comments, even if they do not want to make an official vote or comment on any particular area in which they do not feel they have adequate knowledge. All comments and personal or technical evaluations are important and help a review manager make a final decision, as well as telling a library author what others think of what he has done. With that said I will not try to hide the fact that I personally view the Synapse approach to signal/slot processing as different enough, and useful enough due to its non-intrusive nature, from signals/signals2 to be a valuable addition to Boost, even while I recognize that there was not enough of a consensus or enough of an interest among others during the review to have that happen now. Among the issue brought forth by others my personal view for possibly improving Synapse to where it might be more acceptable to reviewers and might draw more people's interest as a possibly Boost library in the future pending another review, lies mainly in these numbered issues above: 2), 4), 5), 7), 8), 12), 15). I also feel having the documentation discuss in more detail the major concepts of the library, as a bridge between the Tutorial and the Synopsis, would be very helpful for interesting programmers In Synapse. Of course other people's views may vary greatly, and further discussion of Synapse on the Boost developers mailing list or the Boost users mailing list is, I am sure, welcome to the author of Synapse Emil Dotchevski.

1 0

[root_ptr] documentation fix
by Phil Bouchard 14 Dec '16

14 Dec '16

Greetings, I just realized that root_ptr is "container-oriented" and therefore I added this information to the documentation: http://philippeb8.github.io/root_ptr/root_ptr/intro.html#root_ptr.intro.roo… I think this summarizes it all with these few keywords and at some point people will get tired of the garbage collectors and "click" ;) Sincerely, -Phil www.fornux.com www.finitetheory.com www.loaapu.com (in progress)

1 0

[synapse] Review
by David Sankel 14 Dec '16

14 Dec '16

On Fri, Dec 2, 2016 at 9:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > > For your review you may wish to consider the following questions: > > - What is your evaluation of the design? > The design looks reasonable. > - What is your evaluation of the implementation? > I found the use of typedef's to functions returning inline struct definitions to be overly clever and cryptic to new C++ developers. I also found the lack of static type checking in certain places to be objectionable. The unusual formatting is an important subjective turnoff to potential users. Presumably the goal of the library is to enable users to get the functionality they've been missing. The hurdle of a new formatting style to get used to goes against this goal. Fortunately, this is something easily remedied. > - What is your evaluation of the documentation? > Looked reasonable. > - What is your evaluation of the potential usefulness of the > library? > Given the prior existence of Boost.Signals I wouldn't find this library to be useful. There is an important aspect to this review that I want to call out. A signal is a "vocabulary type" in that it is pervasive through systems and frequently used in public interfaces. One of the most important qualities of a vocabulary type is that there be only one of them. Imagine the confusion if we had one thread-safe shared pointer class and another one optimized for single threaded usage, or if we had an suite of different variant types with different tradeoffs. No, there should only be one signal type and Boost.Signal made the correct choice of using a so-called intrusive design. - Did you try to use the library? > Nope. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? > I spent a few hours on the review. A small amount of time was reading the documentation and a much longer amount of time was spent pondering the implications of incorporating the library into Boost. - Are you knowledgeable about the problem domain? > Yes. I've used Qt signals, Boost.Signals1, and Boost.Signals2 extensively in various projects. > - Do you think the library should be accepted as a Boost library? > No. -- David Sankel

4 6

[algorithm] split_copy
by Chambers, Matthew 13 Dec '16

13 Dec '16

I like the simplicity and flexibility of boost::algorithm::split, but whenever I do some one-off, trivial split with it where performance isn't an issue, I find myself wishing that I didn't have to predeclare the result container. That is, I want a split_copy which returns the result container by value, analogous to the many other *_copy functions in boost::algorithm. This turns the split into an easy to read one-liner. Is there a technical reason that this doesn't exist, or just something the boost::algorithms developer didn't think was sufficiently sweet (syntactic-sugar-wise) to add? Thanks, -Matt

2 2

Synapse library review starts today December 2
by Edward Diener 13 Dec '16

13 Dec '16

The formal review of the Synapse library by Emil Dotchevski starts today, December 2, and is scheduled to continue through December 11. This gives two full weekends and the week in between for the formal review. Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html. Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[synapse]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. I encourage all programmers with an interest or knowledge of signal/slot processing to be part of the review or discussion of the Synapse library as your time permits.

8 27

[spirit] [qi] What's the differences between qi::uint_parser<int>() and qi::uint_parser<unsigned int>()?
by Han Wang 13 Dec '16

13 Dec '16

Both of them are the same as qi::uint_(parsing integers from 0 to UINT_MAX). For qi::uint_parser<int>, the required maximum value of numeric base type int is not used at all.

2 1

[release 1.63] required bugfixes
by Oliver Kowalke 13 Dec '16

13 Dec '16

Hi, during the test of boost-1.63 rc 1 some problems occurred (see Marshall's and Stephan's postings). I request to merge my last commits (on branch master) from boost.context and boost.fiber into boost-1.63 (rc 2?) - as well as commit 13f5d9c88ae5363fe547f04c1d272b2a772a8b4d from boost.config. Otherwise the build will fail for gcc-7.1, clang-4.0 and mingw64. best regards, Oliver

1 0

[fiber] Boost.Fiber 1.63.0 RC1 tries to use std::mutex which MinGW doesn't have
by Stephan T. Lavavej 13 Dec '16

13 Dec '16

In both 1.62.0 and 1.63.0 RC1, building Boost.Fiber with my MinGW-w64 distro fails. That's because libstdc++ doesn't natively support the Clause 30 multithreading headers (std::mutex etc.) on Windows, and I make no attempt to build wrappers between the Windows and POSIX APIs (which is my personal choice). Boost's build system should detect this, and use the perfectly valid Boost.Thread implementation. Indeed, "C++11 mutex : no" is printed during the build's configuration, but Fiber's build fails anyways. My configuration output, and the errors emitted by a typical translation unit, are recorded here: https://github.com/StephanTLavavej/mingw-distro/issues/28 Thanks, STL

1 0

copied boost files in other projects
by Oliver Kowalke 12 Dec '16

12 Dec '16

I encountered some projects that have copied files from boost and replaced the copyright and license notice by their own. Other projects have added their own license (for isntance MIT, LGPL ...) beside the Boost license notice in the copied files - does this mean that the code is dual licensed now?. How does the boost community deal with this? Oliver

9 16

Review period has ended for the Synapse library
by Edward Diener 12 Dec '16

12 Dec '16

The review period has officially ended for the Synapse library by Emil Dotchevski. I have received one e-mail specifying a review that will come sometime today and therefore will wait before making my decision as Review Manager for that review and Emil's possible response. I would like to thank all those who took part in the review during the review period, and Emil for responding to the remarks of those who have participated. I know another library will shortly begin its review, but I will not rush my final analysis and decision regarding Synapse and intend to make it sometime by the end of this week. Edward Diener, review manager

1 0

Re: [boost] [synapse] Synapse library review starts today December 2
by Barrett Adair 12 Dec '16

12 Dec '16

On Fri, Dec 2, 2016 at 8:19 AM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > - What is your evaluation of the design? I don't know anything about Signals2, but I find the "non-intrusive" argument to be compelling. I don't like that the invocation mechanism is single-threaded by default. I think the thread_local approach is interesting, but it sounds ripe for confusion in application code. > - What is your evaluation of the implementation? This code style is quite foreign to me, but it seems consistent. The mix of Boost and std libraries seems arbitrary (e.g. boost::shared_ptr and <thread>). The Boost.Function dependency appears redundant. The callback is effectively being erased twice. std::invoke or equivalent could serve as a replacement. I don't much like signal_traits.hpp and the limitations it imposes. Arity is capped at 4 parameters, and the signal type must be passed explicitly. The latter is surely good for compile times, but I think it would be nice to have a deduced signal type version that could still support stateful lambdas and member functions. I browsed the test cases, and they seem rather in-depth. I think some comments in this code are warranted. > - What is your evaluation of the documentation? The tutorial is very well done. Overall, the documentation is very solid. I enjoyed reading it. Quickbooks and syntax highlighting would be nice. This line was disappointing: "requires compiler support for the following C++11 features" I have seen this in existing Boost library documentation, so there is precedent, but I do not like it at all. I much prefer to see a range of tested compiler versions, even if it's only a couple. Continuous integration services like Travis and Appveyor are free, and very useful toward this end. > - What is your evaluation of the potential usefulness of the > library? It appears that it could be useful to Qt users. I personally would not find this useful. > - Did you try to use the library? With what compiler? Did you > have any problems? I ran the logger example with GCC 5.3 on Ubuntu 16.04. No problems. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? 4 hours combined of reading the documentation and playing around with the implementation code. > - Are you knowledgeable about the problem domain? My experience with C++ signal libraries is limited. I am comfortable using the Intel TBB flow graph library, which has some degree of overlap. I have a bit of experience with event-driven programming in other languages. I am knowledgeable about C++ callable types and compiler support for their variations. > - Do you think the library should be accepted as a Boost library? This is my first formal review participation, I don't have a library in Boost, I'm not familiar with Signals2, and I do not have a use case for Synapse, so I'm not going to answer this question. Please consider this message as a "technical comment" instead. P.S. For whatever it's worth, I did fork the Synapse code and implement tentative variadic support in connect.hpp and emit.hpp (though I did not get around to translate.hpp). https://github.com/zajo/boost-synapse/compare/master...badair:master It appears to work as-is with the logger example, but similar work would need to be done in translate.hpp to make it fully variadic. I used my proposed CallableTraits library with the intention of implementing deduced signal types, but I ran out of willpower. Please forgive the aggressive formatting.

2 1

Boost.IOStreams mapped_file_sink missing flush() functionality
by AB 11 Dec '16

11 Dec '16

Hello, I wish to bring to your attention two issues regarding mapped_file_sink from Boost.IOStreams (release 1.62.0): 1. There is no member function `mapped_file_sink::flush()` which I would like to use in my program. I believe it could be implemented portably by using `msync()` for POSIX and `FlushViewOfFile()` for Windows; was the omission of this function a deliberate choice or a minor oversight? 2. The member functions `begin()` and `end()` are implemented for mapped_file_sink but are not documented! This will lead to programmers relying strictly on the docs to use `data()` and `data()+size()` instead. Please update the documentation for the next release 1.63.0.

3 3

[1.63.0] Master is closed for beta release + release notes
by Daniel James 10 Dec '16

10 Dec '16

Hello everyone, The master branch is now closed for the beta release. Please can you add any remaining entries to the release notes, either by emailing me, or by creating a pull request at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… To do so, click on the little pencil icon at the top right of the code. thanks, Daniel

4 3

Synapse library review final 2 days
by Edward Diener 10 Dec '16

10 Dec '16

Today and tomorrow are the last 2 days of the review of the Synapse library by Emil Dotchevski. If anybody intends to review the Synapse library but cannot finish their review this weekend, but will be able to finish their review by this coming Monday, please e-mail me and I will take into account your review when making my decision as Review Manager. I encourage all those who are interested in signal/slot programming to look at Synapse and make a review. Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html.

1 0

[stacktrace] Prereminder of Boost.Stacktrace review starting 14th
by Niall Douglas 10 Dec '16

10 Dec '16

I know we are all likely feeling a bit of tired of reviewing potential new Boost libraries, but I just wanted to remind everyone that Antony's Stacktrace library will start its peer review this coming Wednesday Dec 14th with the review lasting until just before Christmas, Dec 23rd. I appreciate this reminder is a little early given the Synapse review doesn't finish until tomorrow, but today I have the time to do email using both hands, and I likely won't get the time again until next weekend (newborns force a lot of single handed typing with your neck twisted hard to the side. Very slow). Edward I hope this doesn't get in the way of concluding your very interesting review. Antony's Stacktrace library adds a long overdue facility to Boost, a formal portable API for obtaining and parsing the call stack of a thread of execution. It has three user selectable backends, tries to provide a maximum performance (nomalloc) stack capture and I think by now can serialise stacktraces to storage. I'll be honest in saying I sent a long list of fairly strong concerns I had with the design and implementation to Antony last month, but I'll defer in the review to whatever the community votes (increasingly me and the Boost consensus seem to be diverging on what makes for good design and practice). I'll make the formal review announcment on Wednesday, but for those wanting to get started early go to: Github: https://github.com/apolukhin/stacktrace Docs: http://apolukhin.github.io/stacktrace/index.html Regards, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[fusion] Compilation errors on Intel compiler (C++14)
by Andrey Semashev 08 Dec '16

08 Dec '16

Hi, I'm seeing compilation errors coming from Boost.Fusion headers on Sandia-intel-17.0-c++14: http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… Notably, the same tests compile fine in C++11 mode on the same compiler, which makes me think that is related to C++14 mode specifically. Looking at the code, it seems the compiler makes constexpr functions implicitly const-qualified even though it shouldn't in C++14 mode, so it's likely a compiler bug. Still, is it possible to add a workaround?

3 3

Solaris Boost Install headaches
by Paluzzi, Aaron 08 Dec '16

08 Dec '16

Hello, I'm currently banging my head against a Boost install on Solaris 10 Sparc. I started with a 1.57 download and install. This had mild success using the "Getting started" documentation with some compilation errors. I've been asked to upgrade this to 1.62, and now I'm getting errors as follows when I run ./bootstrap.sh $ ./bootstrap.sh -n Building Boost.Build engine with toolset ... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details In the Bootstrap.log file I get the following: ./build.sh: syntax error at line 135: `machine=$' unexpected I've been unable to find any further documentation on this error. Any assistance would be appreciated. Actually an in depth install guide for Solaris would be appreciated. I've had no issues on Windows, but Solaris is giving me migraines.

2 1

Synapse library review ongoing
by Edward Diener 07 Dec '16

07 Dec '16

We are in our final 5 days of the review of the Synapse library. We have had some good discussions about Synapse for those willing to review the library, but we really need much more from those who are, or might be, interested. Without wishing in any way to limit reviews or discussions to specific topics I would like to suggest to those interested in the library that they might address soem of these particular questions about Synapse in their commenst or review: 1) Is the documentation understandable for programming with Synapse ? 2) Does the library successfully achieve what it says it can do, providing a non-intrusive signal/slot system ? 3) Is the Synapse syntax easy enough for a programmer to use ? 4) Does testing show that Synapse works with user's code ? 5) Is the design of the library clear enough and flexible enough to make working with it viable ? While I realize that much of the discussion has been about particular end-user's preferences for a signal/slot library or Synapse's way of doing signal/slot programming versus Boost Signals/Signals2, all important topics in a review, it would be helpful if reviewers or commenters would consider Synapse for what it does do, even if they might not personally find a use for it in their programming tasks. ----------------------------------------------------------------------- Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at 'http://zajo.github.io/boost-synapse/Tutorial.html', or read full documentation at 'http://zajo.github.io/boost-synapse/index.html'. You can also view the documentation locally from your clone of the library at boost/libs/synapse/doc/index.html.

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 07 Dec '16

07 Dec '16

>boost.asynchronous looks to have many of the same features/functionality as HPX. >Can I ask why you chose to reimplement futures/lightweight thread pools/parallel STL/etc, >rather than working on improving HPX to suit your needs? I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds. The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible. It is no coincidence that I'm also the author of Boost.MSM. The encouraged design is a whole lot of state machines, each in its own thread (possibly sharing a thread), sending tasks to threadpools, TCP connections, etc. and waiting for callbacks. Future-based designs do not mix well with state machines' run-to-completion. The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both. >JB >Disclaimer : I have contributed o HPX, but I'm not one of the "German HPC Guys" :) . No hard feeling. I'm grateful for participation and the chance to explain the underlying ideas of the library. Thanks, Christophe

4 25

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 06 Dec '16

06 Dec '16

> The regression matrix in develop of Boost.Geometry contains many new > compilation failures due to: > > > 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' > > 2): > ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: > ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? > ar & serialization::make_array(data_, s);and a > > > The master is still OK. > > Can this be solved? Ping! This is still the case! Robert, can you explain this? It is (of course) not only geometry failing, also ublas or (if there are) other libraries with ublas dependencies: http://www.boost.org/development/tests/develop/developer/numeric-ublas.html All yellow! Thanks, Barend

3 8

Re: [boost] [process] Formal Review starts today, 27 October
by Bjorn Reese 04 Dec '16

04 Dec '16

On 10/27/2016 08:26 AM, Antony Polukhin wrote: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance I withhold judgement for now to give the author an opportunity to respond. At the moment I am unsure whether to vote for conditional acceptance or rejection. > - Your knowledge of the problem domain Advanced on Unix. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design I have a couple of serious concerns. My first concern is about the use of tagged arguments, and especially the redirection operators, in constructors. Instead I propose that the library uses the Named Parameter idiom (see [1], not to be confused with what Niall labelled "tagged name parameter" idiom.) The bp::child object should not execute in the constructor, but rather via operator(). That way we can use the named parameter idiom to build up redirections and similar modifications. For example: auto compile = bp::child("c++").output(bp::null); compile("main.cpp"); // Executes My second concern is about deadlocking. The FAQ shows two ways of deadlocking. I would expect the latter (the ls example) to work without further ado because that is how any newcomer would write their code. My third concern is about the chaining of pipes between processes. The tutorial shows an example where the output of the nm command is forwarded to the c++filt command. However, the forwarding is not done directly from the nm process to the c++filt process, but goes via the parent process. This can incur a performance degradation when nm generates much output. Is it possible to chain them directly? Besides "nm myfile | c++filt" that is. I also have the following minor comments / questions. Is it possible to redirect stderr to stdout? (like 2>&1). The reference documentation only mentions this under asynchronous pipe output. The bp::starting_dir should be renamed to bp::current_path to be consistent with Boost.Filesystem. Consider renaming bp::spawn to avoid confusion with boost::asio::spawn which is how you launch coroutines with Boost.Asio. I am missing a this_process::get_id() function to return the current process identifier. > * Implementation My major concern with the implementation is that the library is only header-only, so I cannot compile it as a static library if I wish to. There are several Boost header-only libraries that allows you to do that. The reason why I find this important for Boost.Process is because I want to avoid getting platform-specific C header files included into my project when I include a Boost.Process header. The library should throw its own process_error exception which inherits from system_error, similar to Boost.Filesystem. I did not investigate the implementation in greater detail. > * Documentation The documentation is lacking an entire chapter with an overall description of the library and the concepts used. For instance: * What are processes and pipes? * What are the possible invocation mechanisms? Some of this is mentioned in the Design Rationale, but that is not the place where developers seek their information. * How to set search paths or the current working directory. * How to use environment variables. * this_process Tutorial / Synchronous I/O: What is the default behaviour when I/O redirections are not specified? Tutorial / Asynchronous I/O: Consider including an example with boost::asio::spawn as a way to obtain the yield context. Reference / child: Does not mention how the life-time of the object and the child process are related. For instance, the documentation on the destructor only mentions that it is a destructor. Reference / cmd: bp::cmd will parse the input string as a sequence of space-separated arguments. Is it spaces or whitespaces? Is it possible to have escapes for arguments that do contain spaces? > * Tests Did not investigate. > * Usefulness A process library is a very useful addition to Boost. > - Did you attempt to use the library? If so: > * Which compiler(s) > * What was the experience? Any problems? Did not try. > - How much effort did you put into your evaluation of the review? About 4-5 hours (one of which was gratuitously donated by daylight saving time.) [1] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Named_Parameter

11 49

API/ABI changes report for Boost
by Ponomarenko Andrey 02 Dec '16

02 Dec '16

Hello, The report on API/ABI changes in the latest releases of Boost: https://abi-laboratory.pro/tracker/timeline/boost/ The report is generated by the open-source abi-tracker tool and updated three times a week. Hope it will be helpful for users and maintainers of the library. Thank you.

1 0

[poly_collection] Request for comments: fast polymorphic collections
by Joaquin M López Muñoz 02 Dec '16

02 Dec '16

A couple of years ago I wrote two blog entries about high-performance data structures for polymorphic objects: http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html that spurred some interest in the community. Now I've had the time to turn these ideas into something resembling a full-fledged library: https://github.com/joaquintides/poly_collection http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html and I'd be very grateful if people could give their opinion on usefulness, design, etc. so as to determine potential interest in an eventual official submission to Boost. Thank you, Joaquín M López Muñoz

6 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>After having a deeper dive into the documentation and examples, one >pattern I see popping up quite >frequently is this: >future<R> fut = my_promise.get_future(); >post_callback(some_work, [this](expected<R> r) { >this->my_promise.set_value(r.get()); }); >return fut; This is simply to make examples easier to run (it finishes the example). It demonstrates that the only one which blocks in an application built on Asynchronous is main(). This might be more confusing than useful and I probably should get rid of this. >Is there any performance/usability drawback from this (might have gotten >the syntax wrong here): >return post_future(pool, some_work); > >Why is the former to be preferred to the latter, or vice versa? post_future is the preferred for simple applications or examples. It is similar to std::async (without the problem of blocking futures and with different continuations). post_callback is the design the library seeks to promote for bigger applications: post a task to a threadpool, get a callback posted to the queue of the caller's thread world. >Regarding the documentation overall, >it seems to miss a proper reference section. >For example, boost::asynchronous::expected is used almost >everywhere, but not documented. My bad. Will be corrected. Thanks, Christophe

2 2

Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

Dear Community, The Asynchronous library is now listed in the Boost Library Incubator ( http://blincubator.com/bi_library/asynchronous-2/?gform_post_id=1654) I took a lot of time since first presenting it in C++ Now 2014 in order to extend the scope and intensively test the library. The library has been in use in production code for already 1.5 years, has survived billions of calls and usage 24/7, so its core is stable and quite tested. All algorithms have not been used though so that bugs are possible there. The reason for using the Incubator is, the library is quite big and 2 weeks review will not be sufficient so I hope for comments, discussions or pre-reviews earlier on. Asynchronous is first of all an architecture tool. It allows organizing a complete application into Thread Worlds, each world having the possibility to use the same or different threadpools for long-lasting tasks. The library provides an implementation of the Active Object pattern, extended to allow many Active Objects to live in the same World. It provides several Threadpools and many parallel algorithms making use of them. And most important of all, it allows simple, blocking-free asynchronous programming based on thread-safe callbacks. It also provides very useful logging and HTML diagnostics (see https://htmlpreview.github.io/?https://raw.githubusercontent.com/henry-ch/a…) to allow better understanding of code. I look forward to an interesting and lively discussion. Christophe

6 7

Upcoming review of the Synapse library starting tomorrow
by Edward Diener 01 Dec '16

01 Dec '16

The formal review of the Synapse library by Emil Dotchevski starts tomorrow, December 2 and is scheduled to continue through December 11. I will be making an official announcement tomorrow, but I want to give the following information today for anyone wishing to acquaint themselves with the library. As explained previously by Emil Dotchevski when requesting that Synapse be put on the Boost Review list, Synapse is a signal programming library, similar to Boost Signals2 and the signals-slots system in Qt. The main difference is that Synapse is non-intrusive: the address of any object of any static type whatsoever can be passed to synapse::emit to emit a signal. This makes it possible to emit Synapse signals from objects of third-party types as well as system objects (e.g. standard FILE pointers, HWNDs, etc.) or any other object that can be converted to a pointer. The library has been formatted to fit the Boost directory and namespace structure. To get Synapse, clone 'https://github.com/zajo/boost-synapse.git' into a directory called 'synapse' under your boost/libs directory. See the tutorial at http://zajo.github.io/boost-synapse/Tutorial.html, or read full documentation at http://zajo.github.io/boost-synapse/index.html. The documentaion can also be viewed from the local clone at boost/libs/synapse/doc/index.html. I would urge anyone who may be interested in signal/slot processing in C++ to take a good look at the Synapse library. Edward Diener, review manager

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 01 Dec '16

01 Dec '16

>I'm trying to digest the docs for this monster work. > >One things that strikes me immediately is that the doc preparation >does not use code snippets, and so code is in boring old >black'n'white rather than colored syntax. >For me, that makes it significantly harder to read (and understand) the code examples. Ok, I'll see if I can improve this. >It also means that one doesn't have the assurance that 'What You See is What Compiles'. For most features, the doc provides a link to an example, which I regularly compile. >(I've also having trouble finding things in all the plentiful 'good stuff'. >But that's a common (and largely still unsolved) >problem with all documentation.) >Paul Please let me know what is the "good stuff" for you and I'll make it more visible. Cheers, Christophe

2 1

[compute] Remove boost::chrono lib dependencie
by Viktor Sehr 01 Dec '16

01 Dec '16

Hi, Would it be possible to remove the dependency for boost/chrono is boost/compute/detail/duration.hpp. As it already supports std::chrono via a macro, couldn't the inclusion of boost/chrono.hpp be excluded? As it is now, boost compute is dependent on having libboost_chrono-vc140-mt-gd-1_62.lib built. /Viktor

4 4

[release] Boost 1.63.0 Beta 1
by Marshall Clow 29 Nov '16

29 Nov '16

The first beta packages for 1.63.0 beta 1 are now available: <https://sourceforge.net/projects/boost/files/boost/1.63.0.beta.1/> The SHA256 checksums are as follows: 3dbc1bca10941710755c13a00b1ae56d2d37fe90bbadcf9746203194f9d33e3a boost_1_63_0.7z c8b986fd57e436fd88dbc70e51d3e21efa2be3bdf835fa499b2cf6c0a8cc2985 boost_1_63_0.tar.bz2 745d99e4be9c0f324ec7ba15b7d228fd780067f2e8aeae2f16660a4cf6e6a051 boost_1_63_0.tar.gz e66bd6e2f637148c314398b92bc1f3cbdc777ee282f9de7885697afad3d9c202 boost_1_63_0.zip As always, the release managers would appreciate it if you download the archive of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

12 21

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Vicente, >> In theory, the standard version would suffice, except for Thread. >> Boost.Thread provides interruption points, which the standard does not. >> With the standard version, I would not be able to offer task interruption. >Could you explain why task interruption is associated to thread >interruption? Ah already implementation details :) Tasks are executed in schedulers (uisually threadpools), which manage 1 to n threads. To interrupt a task from outside, the library interrupts the thread running the task. To be exact, the task will be interrupted the next interruption point in encounters. The thread executing the task does not terminate but instead recovers and pops the next task from its job queue. >> I rely for the other parts also on Boost because the standard version had >> bugs on earlier versions of compilers, and quite some projects are still >> stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain >> using Boost (which also happens to be faster than the standard, at least on >> my tests). >> >Whow, glad to hear Boost.Thread is working for you Henry. It is. I got no problem whatsoever. >I believe that Michael is however right. Boost libraries restricted to >C++11 should use the standard library as much as possible. Sure. At the moment I have no way around Boost.Thread though. If that changes, I'll probably want to switch to standard. The performance issue for the clock is not a huge one and by that time, the older compilers will hopefully have vanished. I could provide a macro to switch between boost / std. If one needn't interrupt tasks, the library would make no use of boost at all. >It would be great to have a specific C++11 (language and standard >library) version of your library. Well, if there is interest, why not? >Good luck with the review, >Vicente >P.S. I've in my todo's list implement thread interruption on top of the >standard as Anthony showed in his book, but I have no time to work on >this now. Oh, it would be great. This really is a fantastic feature. Thanks, Christophe

1 0

Re: [boost] Asynchronous library now in Boost Library Incubator
by Christophe Henry 29 Nov '16

29 Nov '16

Hi Michael, >Thank you for submitting this library to the the incubator in >preparation for a review. I saw your presentation in 2014 >and I believe that this library solves a common problem. >My first question: I see that the library is listed as C++11 and also >has dependencies on Boost.System, Boost.Thread, Boost.Chrono, >and Boost.DateTime. Much of the functionality provided by those >Boost libraries is now part of the C++11 or C++14 standard. >Can you comment on the specific Boost dependencies >and if the standard versions would suffice? A good question which deserves a rationale, which I will add. In theory, the standard version would suffice, except for Thread. Boost.Thread provides interruption points, which the standard does not. With the standard version, I would not be able to offer task interruption. I rely for the other parts also on Boost because the standard version had bugs on earlier versions of compilers, and quite some projects are still stuck with gcc-4.9 or mingw. At some points, it seemed easier to maintain using Boost (which also happens to be faster than the standard, at least on my tests). HTH, Christophe

2 1

[ssl] SSL handshake takes forever sometimes
by Shuchen He 28 Nov '16

28 Nov '16

Hi, I have an application written in boost with SSL. I noticed that when the client network is down for a while and come back again. The SSL handshake sometimes take forever. I tried to kill the client application and run it again, the problem still there. The only way to make it work again was to reboot my client device. I'm using boost 1.60 on the client side and 1.58 on the server side. The SSL handshake code was copied from Boost SSL server and client example I modified a bit to suit my application needs. Does anyone experience the similar issue? If so, can you please let me know how do you fix it? It would be much appropriated if you could help me out on this issue. Below is the SSL handshake code. chat_client(boost::asio::io_service& io_service, boost::asio::ssl::context& context, tcp::resolver::iterator endpoint_iterator) : io_service_(io_service), socket_(io_service, context) { filesize_=0; isfileopen_=false; socket_.set_verify_mode(boost::asio::ssl::verify_peer); socket_.set_verify_callback( boost::bind(&chat_client::verify_certificate, this, _1, _2)); boost::asio::async_connect(socket_.lowest_layer(), endpoint_iterator, boost::bind(&chat_client::handle_connect, this, boost::asio::placeholders::error)); } bool verify_certificate(bool preverified, boost::asio::ssl::verify_context& ctx) { char subject_name[256]; X509* cert = X509_STORE_CTX_get_current_cert(ctx.native_handle()); X509_NAME_oneline(X509_get_subject_name(cert), subject_name, 256); log_time(); fprintf(logfile,"%s: Verifying %s\n",logtime.c_str(), subject_name); return preverified; } void handle_connect(const boost::system::error_code& error) { if (!error) { socket_.async_handshake(boost::asio::ssl::stream_base::client, boost::bind(&chat_client::handle_handshake, this, boost::asio::placeholders::error)); } else { log_time(); fprintf(logfile, " %s Connect to server failed: %s\n ",logtime.c_str(), error.message().c_str()); fflush(logfile); delete this; } } void handle_handshake(const boost::system::error_code& error) { if (!error) { ssl_handshake_ok=1; do_read_header(); } else { log_time(); fprintf(logfile,"%s: Handshake failed:%s\n ",logtime.c_str(), error.message().c_str()); } }

1 0

[poly_collection] request for help at performance testing
by Joaquin M López Muñoz 28 Nov '16

28 Nov '16

Hi, Some days ago I published the first version of (candidate) Boost.PolyCollection at https://github.com/joaquintides/poly_collection Performance tests are available at http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec… but GCC and Clang were run in a Travis VM and the resulting figures are noisy and not sufficiently accurate. I'm looking for volunteers willing to run the performance suite in one or more of the following environments: * Recent GCC, 32 bit * Recent GCC, 64 bit * Recent Clang 32 bit * Recent Clang, 64 bit The full suite in one environment takes 1.5-2h to execute. If you're interested, please contact me privately (so that we don't pollute the mailing list) and I'll provide you with further instructions on how to do the testing. Thank you! Joaquín M López Muñoz

1 0

[iterator] Orbiting iterators
by Jeremy Murphy 27 Nov '16

27 Nov '16

Hi, just wondering what the mood in Boost.Iterator is for new features? At work we recently found use for an orbiting iterator, specifically a circular one, which effectively wraps at the start/end of a bounded range. (The domain is digital signal processing.) Implementation details aside, does this feature sound desirable to the library? I call it an "orbiting" iterator because it is a specific (and useful) case of the more general rho-shaped orbiting iterator. The theory behind it is in chapter 2 of Elements of Programming, which happens to be the free sample chapter available: http://elementsofprogramming.com/032163537X_Sample.pdf#page=6 Anyway, if there is interest, I'll make a pull request. Cheers. Jeremy

6 10

Re: [boost] [beast] Separation between parse and generation and asio
by Vinnie Falco 24 Nov '16

24 Nov '16

On Wed, Nov 23, 2016 at 10:45 PM, Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> wrote: > I'm trying Beast with avr-gcc to see how much footprint it would take > on embedded applications. Thank you for your interest in Beast! > Unfortunately, stream_concepts uses asio > types, which requires asio include which requires network includes > which will obviously fail in most microcontrollers. > > Would it be possible to make parse and read implementation less > dependent on each other? I see what you mean. Yes, I believe I can do that - would you mind creating a new issue here? https://github.com/vinniefalco/Beast/issues Thanks!

1 0

[outcome] Requesting pre-review of Boost.Outcome tutorial
by Niall Douglas 24 Nov '16

24 Nov '16

Dear Boost, I am hoping to bring Boost.Outcome, a C++ 14 library providing a factory and family of policy driven lightweight monadic value-or-error transports, into the Boost peer review queue by March 2017 followed shortly thereafter by an ACCU talk in April if my talk proposal passes their programme committee. To that end, I've written an explanation and a sort of tutorial explaining the history and purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd greatly appreciate if people could tell me: 1. Does it make sense? 2. Do you think you could use Outcome in your own code after reading it? 3. Do you think you would want to use Outcome in your own code after reading it? 4. Are there any missing parts which are showstoppers? My thanks in advance. Be aware the install stuff described at the start doesn't work yet. The reference documentation is also quite patchy thanks to doxygen not understanding CRTP. All that stuff and a fair bit more remains to fix before it's ready to enter the Boost peer review queue. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

6 14

[beast] Separation between parse and generation and asio
by Felipe Magno de Almeida 24 Nov '16

24 Nov '16

Hello, I'm trying Beast with avr-gcc to see how much footprint it would take on embedded applications. Unfortunately, stream_concepts uses asio types, which requires asio include which requires network includes which will obviously fail in most microcontrollers. Would it be possible to make parse and read implementation less dependent on each other? Boost.Spirit x3 works very well on microcontrollers. I'd expect a different type for messages which could actually receive iterator pairs for strings with Beast might give a very good option for HTTP/WS implementation on microcontrollers. Regards, -- Felipe Magno de Almeida

1 0

[sort] Parallel sorting sub-library mini-review conclusion
by Christophe Henry 22 Nov '16

22 Nov '16

> I would like to know the memory used and the best, >normal and worst case of the Asynchronous sorting algorithms. The sort versions are mergesort so they use double memory. The quicksort versions require no extra memory while partitioning. When they degrade after some partitioning iterations, they require the extra memory used by the underlying sort algorithm (spreadsort, std:sort, intro_sort, etc.). Thank you Francisco for this interesting library which I shamelessly used into my own ;-) It's probably a bit late but I vote for acceptance. Cheers, Christophe

2 1

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

>> >> OTOH the single-threaded ones are interesting, especially the stable_sort >> and intro_sort for cases where usage of spreadsort is not possible. >> >I challenge you to find a sorting problem where it isn't possible to use >spreadsort. string_sort can sort anything that std::sort can; > you just need to convert the sort key comparison sequence into a sequence of bytes > and feed string_sort the correct functors. That said, it may not be >efficient to sort some problems with string_sort, >and it'll probably be too much work to be worth the effort for many problems. This is what I meant. Sorry for the lack of precision. I'll add it to my performance tests, it might be an interesting variant as the algorithm is really fast. >> >> A short summary: >> >> 100000000 uint64_t elements already sorted: >> Boost parallel sort : 0.064965 secs >> >> Asynchronous parallel sort : 0.0167134 secs (same with other >> algorithms) >> >> Asynchronous provides a special optimization for this case. >> >If this optimization is practical to incorporate in Boost parallel sort, >it is a common case and your solution seems noticeably faster, >so I would like Francisco to consider it. That said, .06s isn't bad. Sure. >> >> I added this one: >> 100000000 uint64_t elements reverse sorted >> >> Boost parallel sort : 0.581381 secs >> >> Asynchronous parallel sort : 0.0478701 secs >> >> Asynchronous provides a special optimization for this case. >> I this the library should do it too. This one is pretty common and a >> popular DOS attack. >> > This optimization would be nice to have, if it's cheap. A parallel reverse is in O(n) so it's cheap compared to a sort. >> >> 100000000 uint64_t elements randomly filled >> >> Asynchronous parallel quickspreadsort: 0.587432 secs >> Asynchronous quick_intro_sort : 0.728393 secs >> >> This mixing of quicksort degrading into a spreadsort works here best. >I find this algorithm interesting; Frankly, there is nothing special. It's simply a parallel partition, which degrades into a "normal" parallel merge sort (in this case spreadsort) after a while. >have you considered using MSD radix-based sorting to break up the data > for the threads in parallel? >For example, take T threads, have each thread take 1/T of the data > and bucket it into N MSD-based buckets (just like Spreadsort), >where T < N <= ~2^11, then merge the equivalent buckets, >and as you merge them hand them off to another thread to sort. >This will probably divide better if you find the max and min before bucketing >using a parallel min/max search. I admit I didn't. But it sounds really interesting and I think I'll have a go at it. I'm not a sort expert though. I approached this from the parallel perspective. >> 10000000 strings randomly filled >> >> OMP parallel sort : 1.05803 secs >> Boost parallel sort : 0.933055 secs >> >> OMP parallel stable sort : 1.12269 secs >> Boost sample sort : 0.889216 secs >> Boost parallel stable sort : 1.56564 secs >> >> Asynchronous parallel quickspreadsort: 0.788856 secs >> Asynchronous quick_intro_sort : 0.893652 secs >> >> Asynchronous parallel stable sort : 1.23495 secs >> Asynchronous boost::stable sort : 1.21817 secs >> >> Similar results. >> >> >> Let's move on to big objects: >> >> 1562500 elements of size 512 randomly filled >> H E A V Y C O M P A R I S O N >> >> OMP parallel sort : 0.308923 secs >> Boost parallel sort : 0.342992 secs >> >> Asynchronous parallel_quicksort : 0.246709 secs >> Asynchronous quick_intro_sort : 0.269666 secs >> >> Both quicksorts are best, with a slight advantage to intro_sort. >> >> The light comparison is similar. >> >Do we have your permission to copy and/or adapt your quick_intro_sort >algorithm into the Boost.Sort library? Please feel free to copy whatever might be useful. The library has a Boost license as it's intended for inclusion in Boost.I also took the freedom of adding the single-thread versions of Fernando's algorithms as basis for my parallel versions. The algorithm is quite simple. It's the same as quick_spreadsort, a quicksort which degrades into Francisco's intro_sort after some iterations. I just found it interesting to add a wrapper to Francisco's algorithm for the mini-review. It was just a quick test (no time for cleverer algorithms) but I'm pretty satisfied with the result and I'll keep these versions. >How is the worst-case performance relative to Francisco's library? The sort versions have O(n log n) like any merge sort. The quicksort have O(n log n) to O(n^2) as expected from a quicksort. Cheers, Christophe

1 0

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

Hi, > The threads are created only 1 time*. Have I missed something? I checked sample_sort and I saw several sets of calls to std::async which is likely to create and destroy threads several times. >*parallel_sort, sample_sort* : this algorithm is commonly accepted as the >fastest for the parallel stable sort. >The implementation is *notoriously faster than the provided by the GCC compiler* >( based on Open MP ) using less memory. TBB don?t >provide parallel stable sort, and only have an experimental code in their web pages Indeed, I found it highly interesting. Cheers, Christophe

1 0

[release] Boost 1.63.0 - fixes
by Oliver Kowalke 22 Nov '16

22 Nov '16

unfortunately beta 1 does not contain fixes from boost.context and boost.fiber. could you add the fixes to the 1.63 release, please? Oliver

3 4

[sort] Parallel sorting sub-library mini-review starts tomorrow, 11 November
by Steven Ross 22 Nov '16

22 Nov '16

Dear Boost community, The mini-review of Francisco Tapia's Parallel sorting library begins tomorrow November 11, and ends November 20th. The purpose of this review is to assess whether the sub-library is useful and up to Boost software standards. If the Boost community agrees on both, Francisco and I will integrate it into the existing Boost.sort library as a separate sub-library from Spreadsort. In doing so we'll integrate the documentation with the existing documentation for Boost.Sort, making it more consistent. If you review Francisco's library, please make sure you're using a compiler that supports C++11, and answer each of these questions: 1. Were you able to run it and see accurate and fast results? Please specify your compiler, OS, and processor type, and any problems (or slowdowns) encountered. 2. Would you use this library if accepted? Why or why not? 3. What is your evaluation of the design? 4. What is your evaluation of the implementation? 5. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? The library is here: https://github.com/fjtapia/sort_parallel This library provides both stable and unstable sorting algorithms, in single threaded and parallel versions. - All the algorithms have average and worst case runtime of O(NLogN). - These algorithms do not use any other library or utility. To compile and run these you will need a *C++11 compliant compiler.* - *This library is *include only, only requiring* the files in the boost/sort/parallel folder, with no external dependencies.* - The algorithms use a comparison object, in the same fashion as std::sort, defaulting to the std::less object, which uses the < operator internally for comparisons. - The algorithms are exception safe, meaning that the exceptions generated by the algorithms guarantee the integrity of the objects to sort, but not their relative order. If the exception is generated inside the objects (in the move or in the copy constructor) the results can be unpredictable. The library has a a new parallel_sort algorithm *( internally named Block Indirect)*, for processors connected with shared memory*,* invented for the library. This new algorithm combines the speed of algorithms like the GCC parallel sort (based on OpenMP), or the Microsoft parallel buffered sort, with the small memory consumption of algorithms like the TBB sort and the Microsoft parallel Sort. Results from running on an I7 5820 with 12 threads: GCC parallel_sort 1,25 secs 1560 MB TBB parallel_sort 1,64 secs 783 MB Boost parallel_sort 1,08 secs 786 MB In a separate repository (because it uses licence-restricted software like TBB and Microsoft parallel sort, and can’t be included in the Boost library), you can find all the code needed to run the benchmarks, the library code, the benchmark programs, and shell scripts to compile and run it on your machine in Linux and Windows. For the Linux benchmarks you will need to install TBB. (https://github.com/fjtapia/sort_parallel_benchmark) We look forward to your feedback!

4 5

Re: [boost] [sort] Parallel sorting sub-library mini-review. Performance tests.
by Christophe Henry 22 Nov '16

22 Nov '16

Hi Boost Community, I did not manage yet to write a full review. One week is a bit short so a few more days will be necessary. I provide some performance tests first. To check the library performance, I pitted it against my own versions of a parallel mergesort and quicksort provided by the asynchronous library ( https://github.com/henry-ch/asynchronous) which is now ready for review, so we have a stable state for testing. I also added a parallel version inside the asynchronous library using Francisco's single-thread implementations to compare with his parallel ones. I tested on a i7-5960X. Due to time limits, I could not test on more interesting NUMA platforms (I did not get the reviewed library to compile for my KNC) so the tests do not pretend to have value outside the i7 architecture. I linked with tbb_malloc_proxy to limit memory influence. In a nutshell. I'm not a big fan of the parallel version of the algorithms. It seems to be based on std::async, so that a lot of threads are started and joined at every call. I would suggest using a threadpool. OTOH the single-threaded ones are interesting, especially the stable_sort and intro_sort for cases where usage of spreadsort is not possible. Cheers, Christophe A short summary: 100000000 uint64_t elements already sorted: OMP parallel sort : 0.390899 secs Boost parallel sort : 0.064965 secs OMP parallel stable sort : 1.06128 secs Boost sample sort : 0.0695357 secs Boost parallel stable sort : 0.0662401 secs Asynchronous parallel sort : 0.0167134 secs (same with other algorithms) Asynchronous provides a special optimization for this case. I added this one: 100000000 uint64_t elements reverse sorted OMP parallel sort : 0.317039 secs Boost parallel sort : 0.581381 secs OMP parallel stable sort : 1.06448 secs Boost sample sort : 0.524746 secs Boost parallel stable sort : 0.73036 secs Asynchronous parallel sort : 0.0478701 secs Asynchronous provides a special optimization for this case. I this the library should do it too. This one is pretty common and a popular DOS attack. 100000000 uint64_t elements randomly filled OMP parallel sort : 1.03594 secs Boost parallel sort : 0.796447 secs OMP parallel stable sort : 1.28601 secs Boost sample sort : 0.818954 secs Boost parallel stable sort : 1.13604 secs Asynchronous parallel quickspreadsort: 0.587432 secs Asynchronous quick_intro_sort : 0.728393 secs This mixing of quicksort degrading into a spreadsort works here best. The parallel adaptation of intro_sort is not bad either and best of other library algorithms. Asynchronous parallel stable sort : 1.26141 secs Asynchronous boost::stable sort : 0.804814 secs Interesting. The stable version of the library easily beats std::stable_sort I used until now. 10000000 strings randomly filled OMP parallel sort : 1.05803 secs Boost parallel sort : 0.933055 secs OMP parallel stable sort : 1.12269 secs Boost sample sort : 0.889216 secs Boost parallel stable sort : 1.56564 secs Asynchronous parallel quickspreadsort: 0.788856 secs Asynchronous quick_intro_sort : 0.893652 secs Asynchronous parallel stable sort : 1.23495 secs Asynchronous boost::stable sort : 1.21817 secs Similar results. Let's move on to big objects: 1562500 elements of size 512 randomly filled H E A V Y C O M P A R I S O N OMP parallel sort : 0.308923 secs Boost parallel sort : 0.342992 secs Asynchronous parallel_quicksort : 0.246709 secs Asynchronous quick_intro_sort : 0.269666 secs Both quicksorts are best, with a slight advantage to intro_sort. The light comparison is similar. My test code (the modified benchmark.cpp provided by the library): https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/test… The full test results: https://github.com/henry-ch/asynchronous/blob/master/libs/asynchronous/test…

3 2

[process] daemon ideas
by Dracon Pern 21 Nov '16

21 Nov '16

I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated. Thoughts? Thanks, -Eric

4 3

Re: [boost] [iterator] Orbiting iterators
by Jeremy Murphy 20 Nov '16

20 Nov '16

Hi Steve, On 21 Nov 2016 3:01 AM, "Steve M. Robbins" <steve(a)sumost.ca> wrote: > > On Sunday, November 20, 2016 8:25:20 PM CST Jeremy Murphy wrote: > > Hi, > > > > just wondering what the mood in Boost.Iterator is for new features? At work > > we recently found use for an orbiting iterator, specifically a circular > > one, which effectively wraps at the start/end of a bounded range. (The > > domain is digital signal processing.) > > That sounds like what CGAL calls a Circulator; c.f. http://doc.cgal.org/ > latest/Circulator/classCirculator.html Right, yeah. Unfortunately I can't view the documentation properly on my phone so I'll take a look later, but I imagine the principle is the same although the interface is not. > > Implementation details aside, does this feature sound desirable to the > > library? > > I've found these handy when iterating through graph edges incident on a > vertex, when you need to start on a specific edge. It's been ages since I've > used them so I can't recall the exact use case. Makes me wonder whether > something like this already exists in boost graph. As you pointed out with CGAL, domain-specific implementations do exist. Boost.Geometry has something too. I guess I'm interested in whether this need for circular iteration can be abstracted back to the plain old iterator. Cheers. Jeremy

1 0

[outcome] Requesting pre-review of Boost.Outcome tutorial
by Matus Chochlik 20 Nov '16

20 Nov '16

On Fri, Nov 11, 2016 at 8:27 PM, Niall Douglas <s_sourceforge(a)nedprod.com> wrote: > Dear Boost, > > I am hoping to bring Boost.Outcome, a C++ 14 library providing a > factory and family of policy driven lightweight monadic > value-or-error transports, into the Boost peer review queue by March > 2017 followed shortly thereafter by an ACCU talk in April if my talk > proposal passes their programme committee. To that end, I've written > an explanation and a sort of tutorial explaining the history and > purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd > greatly appreciate if people could tell me: > > 1. Does it make sense? > Yes, the explanation is useful and does make sense. > > 2. Do you think you could use Outcome in your own code after reading > it? > > 3. Do you think you would want to use Outcome in your own code after > reading it? > I'm already using something similar in my oglplus2 OpenGL wrapper and some other projects and I really like the technique. IMO the C++ community would benefit from having something like this in Boost. In my implementation the outcome is a pair of the "real" result and an "error info" which can be more elaborate than an error code + a policy which by default throws an exception from the error info when the outcome is destroyed. The function caller can explicitly cancel the throwing and just examine the error information. All functions returning outcome can be noexcept. > > 4. Are there any missing parts which are showstoppers? > I didn't try to use your implementation, but I don't see anything obvious. But a shorter initial tutorial would be helpful. > > > My thanks in advance. Be aware the install stuff described at the > start doesn't work yet. The reference documentation is also quite > patchy thanks to doxygen not understanding CRTP. All that stuff and a > fair bit more remains to fix before it's ready to enter the Boost > peer review queue. > BR, Matus

2 1

Info on Sprout libraries (related to Boost?)
by charleyb123 . 19 Nov '16

19 Nov '16

Looking at the (very impressive) Sprout libraries that distributes using the Boost license: Welcome to the Sprout C++ Libraries <http://bolero-murakami.github.io/Sprout/docs/index.html#welcome-to-the-spro…> C++11 constexpr based Containers, Algorithms, Random numbers, Parsing, Ray tracing, Synthesizer, and others. https://github.com/bolero-MURAKAMI/Sprout ...It appears to be actively maintained, and very interesting. Anybody know the background and roadmap on these libraries (they are not in Boost now, right?) I'm particularly interesting in more 'constexpr' and compile-time libraries showing up, where C++14 (and C++17) wholly "throws-open-the-door" on what you can do at compile time (for example, see the C++14 constexpr used as a full C compiler: https://github.com/kw-udon/constexpr-8cc ) Crazy stuff. --charley

3 2

[fiber] maintenance status
by Tatsuyuki Ishi 18 Nov '16

18 Nov '16

The fiber library seems to be still updated, but I can't get into the author to do a feature proposal or request a refactor. Please take a look at this: https://github.com/boostorg/fiber/issues/89 I have pinged Oliver 3 times, and also sent some emails to his git committer addresses (he uses two identities). If you (the maintainer) are aware of this issue, please respond; I'm willing to do code contributions, but I must have some opinions about that before I get on to the work.

2 1

BOOST_NO_CXX11_HDR_CODECVT confusion
by Robert Ramey 17 Nov '16

17 Nov '16

I use BOOST_NO_CXX11_HDR_CODECVT from config.hpp in order to selectively enable code which uses the built-in codecvt facets as opposed to the boost "home brew" one we've been using for a long time. I do similar things with other macros such as BOOST_NO_CXX11_HDR_FORWARD_LIST. Problems arise when I use a recent compiler such as gcc 6.2 with the switch -std=c++03 as in "/hpc-6.2/usr/local/bin/g++" -ftemplate-depth-128 -std=c++03 -O0 -fno-inline -Wall -g -dynamic -gdwarf-2 -fexceptions -fPIC -arch x86_64 -Wno-unused-variable -Wno-long-long -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_WSERIALIZATION_DYN_LINK=1 -I"../../.." -c -o "../../../bin.v2/libs/serialization/test/test_iterators.test/darwin-6.2~03/debug/test_iterators.o" "test_iterators.cpp" In this ease I would expect to find that BOOST_NO_CXX11_HDR_CODECVT is defined as C++ standard does not include <codecvt> headers for versions prior to C++ 11. But the test matrix http://www.boost.org/development/tests/develop/developer/output/Sandia-gcc-… for this compilers shows that BOOST_NO_CXX11_HDR_CODECVT is NOT defined when no -std=c++03 is used. OK - I see that for gcc 6.2 the default is C++ 14 if no switch is used. So the test matrix is OK. I'm not sure what the column is meant to test as it does specify a particular version as the other columns do. So I think the test for gcc 6.2 - and all the g++/clang compiler would be improved by specifying which version of the C++ standard they are actually testing. But I still have a problem. When I use the swithc -std=c++03 I expect that BOOST_NO_CXX11_HDR_CODECVT be defined as C++ versions prior to C++ 11 don't have header <codecvt>. Same goes for other headers required only for more recent compilers. But my expectations aren't realized as BOOST_NO_CXX11_HDR_CODECVT is not defined in this case. The leads to selection of library code which invokes an #error saying that it's not supported. Perhaps definition of BOOST_NO_CXX11_HDR_CODECVT is conditioned solely on the existence of <codecvt> rather than the existence of <codecvt> and the compiler running in C++ 11+ "mode". I think this is what is messing things up for me. I might be able to work around this if I config.hpp included a macro which indicated which standard version it's intended to support. It doesn't have this. But I wouldn't need it if the BOOST_NO... worked as I would expect. Robert Ramey

3 3

MSVC opensource deployment.
by Robert Ramey 16 Nov '16

16 Nov '16

This just showed up in my junk mail box. Vcpkg updates: Static linking is now available https://github.com/Microsoft/vcpkg With 90+ libraries in its catalog, Vcpkg makes it easier to find the right open source library for Visual C++ 2015. The latest update now supports static linking. This kind of interesting: a) Does this constitute and open-source source code deployment system that perhaps we might learn from/exploit? b) I'm intrigued with the comment under "License": "Code licensed under MIT License" Boost is in this repository - I don't remember changing the Boost license. Robert Ramey

4 5

[Sort] Parallel Sorting Mini review ends November 20th (Need reviewers)
by Francisco José Tapia 16 Nov '16

16 Nov '16

Dear Boost community, The mini-review of Francisco Tapia's Parallel sorting library began in November 11, and ends November 20th. The purpose of this review is to assess whether the sub-library is useful and up to Boost software standards. If the Boost community agrees on both, Francisco and I will integrate it into the existing Boost.sort library as a separate sub-library from Spreadsort. In doing so we'll integrate the documentation with the existing documentation for Boost.Sort, making it more consistent. If you review Francisco's library, please make sure you're using a compiler that supports C++11, and answer each of these questions: 1. Were you able to run it and see accurate and fast results? Please specify your compiler, OS, and processor type, and any problems (or slowdowns) encountered. 2. Would you use this library if accepted? Why or why not? 3. What is your evaluation of the design? 4. What is your evaluation of the implementation? 5. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? The library is here: https://github.com/fjtapia/sort_parallel This library provides both stable and unstable sorting algorithms, in single threaded and parallel versions. - All the algorithms have average and worst case runtime of* O(NLogN).* - These algorithms *do not use any other library or utility*. To compile and run these you will need a *C++11 compliant compiler.* - This library is *include only*, only requiring the files in the boost/sort/parallel folder, with no external dependencies. - The algorithms *use a comparison object*, in the same fashion as std::sort, defaulting to the std::less object, which uses the < operator internally for comparisons. - The algorithms are *exception safe*, meaning that the exceptions generated by the algorithms guarantee the integrity of the objects to sort, but not their relative order. If the exception is generated inside the objects (in the move or in the copy constructor) the results can be unpredictable. The library has a a* new parallel_sort algorithm ( internally named Block Indirect)*, for processors connected with shared memory, *invented for the library*. This new algorithm combines the speed of algorithms like the GCC parallel sort (based on OpenMP), or the Microsoft parallel buffered sort, with the small memory consumption of algorithms like the TBB sort and the Microsoft parallel Sort. Results from running on an I7 5820 with 12 threads: - GCC parallel_sort 1,25 secs 1560 MB - TBB parallel_sort 1,64 secs 783 MB - Boost parallel_sort 1,08 secs 786 MB In a *separate repository* (because it uses licence-restricted software like TBB and Microsoft parallel sort, and can’t be included in the Boost library), you can find *all the code needed to run the benchmarks*, the library code, the benchmark programs, and shell scripts to compile and run it on your machine in Linux and Windows. For the Linux benchmarks you will need to install TBB. (https://github.com/fjtapia/sort_parallel_benchmark) We look forward to your feedback!

1 0

[MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

Dear Community, About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP. Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year. As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead. My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them. This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources. Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations. Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015). I hope this is a reasonable proposal and I look forward into your opinions about it. ** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux): //Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>; // GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s //Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>; // GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ Regards, Bruno Dutra

12 48

Re: [boost] [MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

On Nov 15, 2016 23:57, "Peter Dimov" <lists(a)pdimov.com> wrote: > > Bruno Dutra wrote: > >> Meanwhile, following Rene's suggestion to move away from Travis' container based infrastructure, I was also able to run tests on Clang 3.9 and even on what seems to be nightly snapshots of Clang 4.0: >> >> https://github.com/brunocodutra/metal/blob/develop/.travis.yml. > > > I don't care that much for 3.9 and 4.0, but the -stdlib=libc++ option is intriguing. Does it require sudo? I just checked and libc++-dev is whitelisted on Precise images, so it shouldn't require sudo. That said, the version of libc++ available on such an old version of Ubuntu might not fit your needs (it didn't mine) so you might need to upgrade to Trusty, in which case I believe it requires sudo, because it doesn't seem to be whitelisted yet.

1 0

[fiber] destruction order fiasco
by Tatsuyuki Ishi 15 Nov '16

15 Nov '16

The fiber still makes use of the scheduling algorithm after main context exits, which is a problem for my case that puts a stack-allocated shared data to the algorithm. Some points: https://github.com/boostorg/fiber/blob/master/src/context.cpp#L52 I doubt if the schwarz counter is needed; isn't it only one? https://github.com/boostorg/fiber/blob/master/src/scheduler.cpp#L137 I don't think there's a need to wake it up; if it's sleeping, the thread is blocked and it never enters here. This is the main problem: use-after-free. Anyway, what I think is ideal is that just making the algorithm a reference and assign it from the main context. An example of this approach is Qt's Q*Application.

1 0

Re: [boost] [Boost-users] [process] Formal review results
by Bjorn Reese 13 Nov '16

13 Nov '16

On 11/09/2016 07:45 PM, Antony Polukhin wrote: > The Boost.Process library is accepted. Unconditionally? Please notice that some of the votes were conditional, and if those conditions are not met, they should be counted as no votes. > The most controversial part of the library is it's interface. Many > comments were addressing: > * passing arguments > * starting process right in `system(...)` function The comments were about starting the process in the child constructor.

4 3

Boost.Config for clang on Linux with libc++
by Belcourt, Kenneth 13 Nov '16

13 Nov '16

Hi, Attached are user.hpp and the console output from running configure with clang-3.9. Note that I tried to configure using libc++ but the configure script immediately failed, so these are the results for clang-3.9 with the default stdlib (libstdc++). Can someone please take a look and see what adjustments might need to be made to Boost.Config to support this configuration? Once it works for the default stdlib, I’d like to rerun it to use libc++. Thanks, Noel Belcourt

3 4

[process] Formal Review
by Nat Goodspeed 13 Nov '16

13 Nov '16

I would like to surface a number of issues, large and small. You are clearly proud to support a number of different syntactic ways to express the same semantic operation. To me this is a minor negative. While in theory it sounds nice to be able to write Process consumer code any way I want, in a production environment I spend more time reading and maintaining other people's code than I do writing brand-new code. Since each person contributing code to our (large) code base will select his/her own preferred Process style, I will be repeatedly confused as I encounter each new usage. I admire the support for synchronous pipe I/O, while remaining skeptical of its practical utility. Synchronous I/O with a child process presents many legitimate opportunities for deadlock: traps for the unwary. I would be content with a combination of: * async I/O on pipes (yes, using Asio) * system() for truly simple calls * something analogous to Python's subprocess.Popen.communicate(): pass an optional string for the child's stdin, retrieve a string (or, say, a stringstream) for each of its stdout and stderr. The example under I/O pipes the stdout from 'nm' to the stdin of 'c++filt'. But the example code seems completely unaware that c++filt could be delayed for any of a number of reasons. It assumes that as soon as nm terminates, c++filt must have produced all the output it ever will. I worry about the Process implementation being confused about such issues. I'm dubious about the native_environment / environment dichotomy. As others have questioned, why isn't 'environment' a typedef for a map<string, string> (or unordered_map)? I understand that you desire to avoid copying the native process environment into such a map until necessary, but to me that suggests something like an environment_view (analogous to string_view) that can perform read-only operations on either back-end implementation. Operations involving splitting and joining on ':' or ';' should be defined purely in terms of strings and ranges of strings. They should not be conflated with environment-map support. The documentation so consistently uses literal ';' as the PATH separator that I worry the code won't correctly process standard Posix PATH strings. At this moment in history, an example showing integration of Process with Boost.Fiber seems as important as examples involving coroutines. Why is the native_handle_t typedef in the boost::this_process namespace? While in full context it makes sense to speak of "assigning" an individual process to a process group, the method name assign() has conventional connotations. Use add() instead. There's a Note that says: "If a default-constructed group is used before being used in a process launch, the behaviour is undefined." I assume you mean "destroyed before being used," but this is a concern. If a program has already instantiated a process group, but for any reason decides not to (or fails to) launch any more child processes, does that put the entire parent process at risk? What remedial action can it take? Move the group object to the heap somewhere and let it leak? Spawn a bogus child process for the purpose of defusing the ticking process group instance? If you're going to reify process group at all, you should wrap more logic around it to give it well-defined cross-platform behavior. And it should definitely be legal to create and destroy one without associating any child process with it. Given support elsewhere for splitting/joining PATH strings, the string_type path parameter to search_path() feels oddly low-level. Maybe accept a range of strings? > At a minimum, kindly state: > - Whether you believe the library should be accepted into Boost > * Conditions for acceptance YES, IF the present Boost.Process preserves the ability of its predecessor to extend it without modifying it. I'm sorry, thorough reading of the documentation plus some browsing through the code leaves me doubtful. Examples of such extensions: * With Boost.Process 0.5 I can use Boost.TypeErasure to pass an "initializer" which is a runtime collection of other initializers. Such a feature in Process 0.6 would support people's requests to be able to assemble an arbitrary configuration with conditional elements and use it repeatedly. * I can create an initializer (actually one for each of Posix and Windows, presenting the same API, so portable code can use either transparently) to implicitly forcibly terminate the child process being launched when the parent process eventually terminates in whatever way. Please understand that I am not asking for the above features to be absorbed into the Process library: I am asking for a Process library extensible enough that I can implement such things with consumer code, without having to modify the library. Perhaps Process 0.6 already is! It's just hard for me tell. Another feature should, in my opinion, be incorporated into the library: * On Windows, if you desire to pass any file handles at all to the new child process, it is completely whimsical what *other* open file handles you may inadvertently pass -- unless you play games with STARTUPINFOEXA and PROC_THREAD_ATTRIBUTE_LIST to enumerate exactly the set of handles you intend to pass. If the library doesn't natively support that, I *must* be able to pass a custom initializer with deep access to the relevant control blocks to set it up. This is a showstopper, as in "you can't remove that file because, unbeknownst to you, some other process has it open." > - Your knowledge of the problem domain I have hand-written process-management code in C++ several times before -- each with multiple implementations to support multiple platforms. I have tested the previous candidate Boost.Process 0.5 with a number of programs exercising a number of features. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design Design notes are at the top of this mail. > * Implementation I have only glanced over parts of the implementation. It seems somewhat more obscure than the corresponding pieces of Process 0.5, which is why I couldn't quickly satisfy myself as to the library's extensibility. > * Documentation Others have noted that the documentation is very sketchy in places. I too wish for more explanation. Much of the time I spent on this review was reading through the documentation. Apologies if I have misunderstood the library's capabilities. > * Usefulness I have felt for years now that it is essential to get a child-process management library into Boost. It grieves me to have to write platform-specific API calls into different applications. > - Did you attempt to use the library? I did not, sorry, ran out of time -- as you can infer from this review arriving at the end of the final day! > - How much effort did you put into your evaluation of the review? Most of my time was spent reading the documentation. I looked through a couple of the implementation files for further information.

4 8

Visual Studio 2015 Update 3 has removed std::unary_function and std::binary_function
by Marshall Clow 12 Nov '16

12 Nov '16

... if you build with /std:c++latest. See https://svn.boost.org/trac/boost/ticket/12586 for an example. Other vendors will be removing these types in C++17 mode in the future (or at least requiring a -D RETAIN_REMOVED_STUFF=1 or something like that) A quick grep for these terms found 153 instances of "std::unary_function" and 118 of "std::binary_function" across several libraries, including accumulators, algorithm, config, container, function, gil, graph, icl, mpi, msm, polygon, ptr_container, serialization, smart_ptr, tr1, unordered, utility - and probably others. I think that we ought to have a boost-wide solution for this (i.e, everyone should solve this the same way). I can think of three possibilities: * Deny, deny, deny: Boost doesn't work with C++17. Not my recommendation. * Since std::unary|binary_function is an empty struct with a set of two (or three) typedefs, just define the typedefs everywhere. Note that the typedefs (result_type, first_argument_type, second_argument_type) were deemed to not be useful in C++17 due to the existence of advanced type traits, etc. * Define a boost:unary_function and boost::binary_function struct that mimics the one that was in namespace std, and change over to use that. * Something else. Comments? -- Marshall

15 74

Adding any_dynamic_cast?
by Peter Dimov 12 Nov '16

12 Nov '16

I stumbled across https://github.com/bytemaster/Boost.DynamicAny which implements, in a fully backward compatible manner, dynamic cast functionality for boost::any. That is, it can give you X* from an 'any' holding a value of type Y if Y derives from X. It achieves this by simply changing template<typename ValueType> class holder : public placeholder { ValueType held; to template<typename ValueType> class holder : public placeholder, public ValueType which then enables dynamic_cast from holder<>* to OtherValueType*. This is pretty cool, and I don't remember seeing this idea anywhere else. Perhaps we should adopt it? One might even argue that this is how any_cast should always have worked, but I suppose we can't change it now for compatibility reasons. Although it's an interesting question whether C++17 'any' shouldn't be enhanced in this manner.

2 2

Request for a new submodule, tools/depinst
by Peter Dimov 12 Nov '16

12 Nov '16

I'd like to request the creation of a new submodule, tools/depinst, that will contain a Python script depinst.py which would, given a module in libs/, install the dependencies needed for running that module's tests. Currently, the .travis.yml files I use enumerate the dependencies manually, which is a bit tiresome: https://github.com/boostorg/function/blob/develop/.travis.yml - git submodule init libs/algorithm - git submodule init libs/align ... - git submodule init libs/type_traits - git submodule init libs/typeof - git submodule init libs/utility - git submodule init libs/winapi - git submodule init tools/build - git submodule update --depth 1 This will be replaced by just - git submodule update --init --depth 1 tools/depinst - git submodule update --init --depth 1 tools/build - python tools/depinst/depinst.py function

5 19

[CI] Activation for Boost.Units
by Jürgen Hunold 11 Nov '16

11 Nov '16

Hi Rene, could you please activate CI via Travis CI and Appveyor for Boost.Units? I hope that I have successfully adapted the scripts from Boost.Predef and that they work for Units as well. Is there any way to get myself some admin rights so I can scheduled cron jobs on TravisCI? I'd like to have at least a weekly run in order to check that no other library break units. And I noticed that the scripts don't work for my fork on GitHub. It needs to detect that and add a remote to the submodule in the Boost checkout somehow. Do you have any plans for that? 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

2 1

[Beast] std::to_string not available in gcc 4.8?
by Vinnie Falco 11 Nov '16

11 Nov '16

A user is complaining that std::to_string is not available in their distribution. Beast doesn't support toolchains that don't have full support for C++11. However, if this is the only thing missing maybe I can just use a Boost equivalent to get him up and running. I see boost::to_string in <boost/exception/to_string.hpp> is that a public interface? It doesn't look documented. What do folks typically do when they want to call std::to_string on an unsupported distribution?

4 4

libs/regex/build/Jamfile.v2 missing "import testing"
by Peter Dimov 10 Nov '16

10 Nov '16

In a partial installation (not all submodules installed), running b2 in the Boost root says: libs\regex\build\Jamfile.v2:93: in modules.load ERROR: rule "unit-test" unknown in module "Jamfile<D:\tmp2\boost-root\libs\regex\build>". because libs/regex/build/Jamfile.v2 uses the unit-test rule, defined in testing.jam, but does not have "import testing ;". Adding that line fixes it. I've no idea why it works in a full installation - probably because someone else imports testing first before it gets to regex.

2 1

[process] Formal review results
by Antony Polukhin 09 Nov '16

09 Nov '16

The Boost.Process library is accepted. Congratulations to Klemens, and thanks to everybody who reviewed the library! The votes were as follows: + Johannes - Niall Douglas +/- Tom Kent +/- Nat Goodspeed + Paul A. Bristow +/- Bjorn Reese + Edward Diener + Boris Schäling +/- Raphaël Londeix + Klaim - Joël Lamotte Legend: + accept - decline +/- accept conditionally Separate thanks to Gavin Lambert for providing a solution to deadlocking problem. Additional thanks to Nat Goodspeed, Niall Douglas, Gavin Lambert, Raphaël Londeix and Bjorn Reese for spending significant amount of time on discussing, reviewing or testing the library. -- Quick review summary -- During the review multiple technical issues were raised and as far as I know, Klemens already working on them. The biggest win of the review - is a fix for possible deadlock with pipes. The most controversial part of the library is it's interface. Many comments were addressing: * passing arguments * starting process right in `system(...)` function Current approaches have benefits and drawbacks, other approaches have different benefits and drawbacks. At this point some people agree that the current approach is the lesser evil. Reviewers also wished to have better/richer documentation. P.S.: Please continue with the discussion and report issues that would help to improve the library. -- Best regards, Antony Polukhin

3 3

[dll] trouble building boost dll with Intel compiler on Windows
by Blower, Melanie 09 Nov '16

09 Nov '16

Hello, We are having trouble building boost_dll version 1.61 with Intel compiler (version 17.0) on Windows with vs2015 (and other versions of visual studio). There's a problem because the macro configuration causes alias.hpp to use gnu-like syntax to specify section names: we don't support this syntax in our Windows compiler. Instead, we support "#pragma section" just like the Microsoft compiler. Alias.hpp would use the "correct" configuration for our Windows compiler "#if BOOST_COMP_MSVC" (reference the file boost/dll/alias.hpp) However, the file boost/predef/compiler/visualc.hpp sets BOOST_COMP_MSVC to BOOST_VERSION_NUMBER_ZERO which is 0 I propose that alias.hpp could use BOOST_COMP_MSVC_BUILD instead of BOOST_COMP_MSVC. Does that seem reasonable? Thanks and regards, Melanie Blower (I work for Intel on the Intel C++ compiler)

5 11

[fusion] trouble building boost fusion with Intel compiler on Windows and Linux
by Blower, Melanie 09 Nov '16

09 Nov '16

Hello, We are having trouble building boost_fusion version 1.61 with Intel compiler (version 17.0) on Linux, and on Windows with vs2015 (and other versions of visual studio). The problem can be fixed if I made this change to boost/fusion/container/vector/detail/config.hpp : // Sometimes, MSVC 12 shows compile error with std::size_t of template parameter . #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1800)) \ || BOOST_INTEL /* add this line */ # if defined(BOOST_FUSION_HAS_VARIADIC_VECTOR) # undef BOOST_FUSION_HAS_VARIADIC_VECTOR # endif #endif Symptom on Windows: ile ..\..\..\bin.v2\libs\fusion\test\fold.test\cc848a939769f1f7cf08091b8a228ddb\algorithm\fold.obj.rsp "algorithm\fold.cpp" -Fo"..\..\..\bin.v2\libs\fusion\test\fold.test\cc848a939769f1f7cf08091b8a228ddb\algorithm\fold.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /nologo /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qvc14 -Qpchi- /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 "-I..\..\.." compile-c-c++ ..\..\..\bin.v2\libs\fusion\test\fold.test\cc848a939769f1f7cf08091b8a228ddb\algorithm\fold.obj icl @"..\..\..\bin.v2\libs\fusion\test\fold.test\cc848a939769f1f7cf08091b8a228ddb\algorithm\fold.obj.rsp" fold.cpp ../../../boost/fusion/container/vector/vector.hpp(71): error: namespace "boost::fusion::vector_detail::result_of" has no member "value_at_c" : boost::is_convertible<Sequence, typename result_of::value_at_c<This, 0>::type> ^ detected during: instantiation of class "boost::fusion::vector_detail::is_convertible_to_first<Sequence, This, <unnamed>> [with Sequence=int, This=boost::fusion::vector<int>, <unnamed>=1]" at line 305 instantiation of "boost::fusion::vector<T...>::vector(U &&...) [with T=<int>, U=<int>]" at line 159 of "algorithm\fold.cpp" Symptom on Linux: The original failure on Linux (zip.test in boost_fusion) "icpc" -c -xc++ -O0 -g -w1 -inline-level=0 -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "../../../bin.v2/libs/fusion/test/zip.test/intl-lnx/dbg/algorithm/zip.o" "algorithm/zip.cpp" ../../../boost/fusion/container/vector/vector.hpp(230): error: pack "U" does not have the same number of elements as "I" : store<I, T>(std::forward<U>(var))... ^ detected during: instantiation of "boost::fusion::vector_detail::vector_data<boost::fusion::detail::index_sequence<I...>, T...>::vector_data(boost::fusion::vector_detail::each_elem, U &&...) [with I=<0UL, 1UL>, T=<boost::fusion::vector_iterator<const boost::fusion::vector<int, int>, 0>, boost::fusion::vector_iterator<const boost::fusion::vector<char, char>, 0>>, U=<const boost::fusion::transform_view<const boost::fusion::vector<const boost::fusion::vector<int, int> &, const boost::fusion::vector<char, char> &>, boost::fusion::detail::poly_begin, boost::fusion::void_> &>]" at line 306 instantiation of "boost::fusion::vector<T...>::vector(U &&...) [with T=<boost::fusion::vector_iterator<const boost::fusion::vector<int, int>, 0>, boost::fusion::vector_iterator<const boost::fusion::vector<char, char>, 0>>, U=<const boost::fusion::transform_view<const boost::fusion::vector<const boost::fusion::vector<int, int> &, const boost::fusion::vector<char, char> &>, boost::fusion::detail::poly_begin, boost::fusion::void_> &>]" at line 41 of "../../../boost/fusion/view/zip_view/zip_view_iterator.hpp" Thanks and regards, Melanie Blower (I work for Intel on the Intel C++ compiler)

3 4

test: Initializiation of data test cases
by Florian Lindner 09 Nov '16

09 Nov '16

Hello, I would like to use data test cases. The problem that comes with that, is that I want to use objects that needs the application to be initialized before they are instantiated. Example is that an object that uses MPI needs to habe MPI_Init called before. This example code shows the order in which different hooks are run: #define BOOST_TEST_DYN_LINK // #define BOOST_TEST_MAIN #include <boost/test/unit_test.hpp> #include <boost/test/data/test_case.hpp> #include <boost/test/data/monomorphic.hpp> #include <mpi.h> #include <iostream> #include <string> #include <vector> using namespace std; struct GlobalFixture { GlobalFixture() { cout << "GlobalFixture" << endl; } ~GlobalFixture() { } }; BOOST_GLOBAL_FIXTURE(GlobalFixture); struct Test : public std::string { // derive from string to get operator<< that boost requires Test() { cout << "Object to test" << endl; } }; namespace bdata = boost::unit_test::data; template <class T> class RuntimeDataset { public: using sample = typename T::value_type;; enum { arity = 1 }; T data; explicit RuntimeDataset(T _data) { cout << "Dataset constructor" << endl; data = _data; } bdata::size_t size() const { return data.size(); } typename T::const_iterator begin() const { return data.cbegin(); } }; namespace boost { namespace unit_test { namespace data { namespace monomorphic { template <class T> struct is_dataset<RuntimeDataset<T>> : boost::mpl::true_ {}; }}}} struct Fixture { Fixture() { cout << "Fixture" << endl; } }; BOOST_AUTO_TEST_SUITE(MySuite) BOOST_DATA_TEST_CASE_F( Fixture, test1, RuntimeDataset<std::vector<Test>>( { Test() } ), // This should be evaluated when the test is about to run input) { BOOST_TEST(true); cout << "Data test case" << endl; } BOOST_AUTO_TEST_SUITE_END() // initialization function: bool init_unit_test() { cout << "init_unit_test" << endl; return true; } // entry point: int main(int argc, char* argv[]) { cout << "main" << endl; int retCode = boost::unit_test::unit_test_main( &init_unit_test, argc, argv ); return retCode; } I've removed some code parts, but it should compile right away using mpic++ -std=c++11 -lboost_unit_test_framework boosttesting.cpp Its output is Object to test Dataset constructor main init_unit_test GlobalFixture Running 1 test case... Fixture Data test case *** No errors detected So, before I have any chance to do my own initialization code, the Test object and the dataset is constructed. I have posted this to the user mailing list, but still looking for a way to work around that. Do you have any idea how I can do initialization before data is instantiated? Thanks, Florian

1 0

cross-compiling linux->osx: file was built for archive which is not the architecture being linked (x86_64)
by Frédéric Bron 09 Nov '16

09 Nov '16

I am trying to cross-compile for osx from linux using clang. When I build boost, I use the following: CC="x86_64-apple-darwin13-clang" CFLAGS="-O2 -DNDEBUG" CXX="x86_64-apple-darwin13-clang++-libc++" CXXFLAGS="-O2 -DNDEBUG -std=c++14" AR="x86_64-apple-darwin13-ar" AS="x86_64-apple-darwin13-as" RANLIB="x86_64-apple-darwin13-ranlib" ./bootstrap.sh --without-icu --prefix=/softs/usr/darwin13-clang/release/boost --with-toolset=clang Then I use the following user-config.jam: using clang : : x86_64-apple-darwin13-clang++-libc++ : <cxxflags>-std=c++14 ; with the following command: ./b2 -d2 -j8 --layout=system --user-config=user-config.jam --without-mpi --without-python --without-context --without-coroutine link=static threading=multi runtime-link=shared target-os=darwin threadapi=pthread address-model=64 define=BOOST_THREAD_USE_LIB define=BOOST_LOG_WITHOUT_EVENT_LOG variant=release install Apart from a few errors, everythings looks fine: ...failed updating 3 targets... ...skipped 3 targets... ...updated 13684 targets... However, when I link against the static libraries that have been built, I get this type of messages: ld: warning: ignoring file /softs/usr/darwin13-clang/release/boost/lib/libboost_system.a, file was built for archive which is not the architecture being linked (x86_64): /softs/usr/darwin13-clang/release/boost/lib/libboost_system.a I suspect that it is because the wrong ar and ranlib where used because I find in my log that b2 used "ar" and "ranlib" instead of "x86_64-apple-darwin13-ar" and "x86_64-apple-darwin13-ranlib". So I changed my user-config.jam to: using clang : : x86_64-apple-darwin13-clang++-libc++ : <cxxflags>-std=c++14 <archiver>x86_64-apple-darwin13-ar <ranlib>x86_64-apple-darwin13-ranlib ; but b2 is still using "ar" and "ranlib". Any idea of what my problem is? Frédéric

1 1

Support for fixed point arithmetic in Boost?
by Juan Dent 08 Nov '16

08 Nov '16

Hi, Sorry if this is a dumb question but I have been looking for fixed point types in Boost and not found any... Yet I feel there must be... Thanks for any help Juan

4 5

Fw: Build failed: smart_ptr 1.0.31-develop
by Peter Dimov 08 Nov '16

08 Nov '16

I'm getting a weird error from the CI: https://ci.appveyor.com/project/pdimov/smart-ptr/build/1.0.31-develop C:/projects/boost-root/tools/build/src\build-system.jam:982: in load *** argument error * rule boostcpp.post-build ( ok ? ) * called with: ( ok ok ) * extra argument ok C:/projects/boost-root\boostcpp.jam:513:see definition of rule 'boostcpp.post-build' being called C:\projects\boost-root\tools\build\src/kernel\modules.jam:295: in import C:\projects\boost-root\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\projects\boost-root\boost-build.jam:17: in module scope Command exited with code 1 This is Submodule path 'tools/build': checked out '32113ca3ddbc637d08e85c44502f3149d37323e0'

2 1

[process] The Formal review preiod is nearing the end
by Antony Polukhin 07 Nov '16

07 Nov '16

Dear Boost community, The formal review of Klemens David Morgenstern's Process library ends on 5th November. If you're willing to write a review - please hurry up! If you're willing to write the review but could not make it on time - please give a hint. In that case it is possible to postpone the final decision for a few days. Thanks in advance! -- Best regards, Antony Polukhin

5 8

[process] Formal review has ended
by Antony Polukhin 07 Nov '16

07 Nov '16

The library review has ended. I will need a few more days to calculate the votes and to wait for some people that spend a lot of time to make their vote more explicit. At this point, following people voted: * Johannes * Niall Douglas * Tom Kent * Paul A. Bristow * Bjorn Reese * Edward Diener * Boris Schäling If I've missed someone, please notify me. -- Best regards, Antony Polukhin

2 2

[iostreams] Last develop commit breaks release builds.
by Rene Rivera 07 Nov '16

07 Nov '16

FYI.. This commit: < https://github.com/boostorg/iostreams/commit/0a87de8932641a3896f49872a3c034… > Is causing release build errors. See the CI logs for details.. <https://circleci.com/gh/boostorg/boost/2190> Please address ASAP. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

[config] std::shuffle support
by Edward Diener 07 Nov '16

07 Nov '16

Does Boost config currently have a macro to determine whether the c++11 std::shuffle algorithm is supported for a particular compiler ? If not supporting /std:c++latest by changing std::random_shuffle to std::shuffle will not be possible for c++03 libraries.

3 6

interest in structure of arrays container?
by Michael Marcin 06 Nov '16

06 Nov '16

Structure of arrays is a pretty well known pattern for improving memory density and enabling vectorization in high performance code. Also known as parallel arrays[1]. After hand-rolling yet another of these it occurred to me that you make a reasonable first implementation with a simple alias template. template< typename... Ts > using soa = std::tuple< std::vector<Ts>... >; example: soa<int,float,std::string> data; This is decent start but has several issues including: * nothing to preserve the invariant keeping the arrays the same length * missing coalesced interface for vector methods (size, reserve, etc) * no iterator * wasted storage for duplicated allocators, capacities, sizes * sizeof...(Ts) allocations could be a single large block The work required to address these issues is not too great I think. Potential names: soa<Ts> structure_of_arrays<Ts> parallel_array<Ts> struct_array<Ts> parallel_vector<Ts> struct_vector<Ts> Does this already exist somewhere? Does it seem useful? [1]https://en.wikipedia.org/wiki/Parallel_array

10 79

Re: [boost] [process] Formal Review starts today, 27 October
by Bjorn Reese 06 Nov '16

06 Nov '16

On 10/30/2016 02:21 PM, Bjorn Reese wrote: > On 10/27/2016 08:26 AM, Antony Polukhin wrote: > >> - Whether you believe the library should be accepted into Boost >> * Conditions for acceptance > > I withhold judgement for now to give the author an opportunity to > respond. At the moment I am unsure whether to vote for conditional > acceptance or rejection. I vote for conditional acceptance, provided the following conditions are met: 1. The interface style must be redesigned such that: a. There is a clear separation between arguments and attributes. b. Arguments and attributes should not be arbitrarily interspersed in the parameter list. c. A set of attributes can be build in advance, and reused for different child processes. d. Attributes can be optionally to the attribute-set. 2. There should be no I/O deadlocks by default. 3. An Overview section that introduces the concepts and the various parts of the library must be added to the documentation.

1 0

[process] Formal Review starts today, 27 October
by Antony Polukhin 05 Nov '16

05 Nov '16

Dear Boost community, The formal review of Klemens David Morgenstern's Process library begins today, 27th October and ends on 5th November. Process is a C++11 library to manage system processes. It can be used to: * create child processes * setup streams for child processes * communicate with child processes through streams (synchronously or asynchronously) * wait for processes to exit (synchronously or asynchronously) * terminate processes Full documentation with examples and tutorial is available at http://klemens-morgenstern.github.io/process/index.html Stable source codes for review are available at https://github.com/klemens-morgenstern/boost-process/tree/boost_review Latest source codes available at https://github.com/klemens-morgenstern/boost-process We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? We await your feedback! -- Best regards, Antony Polukhin

10 38

[process] Formal Review
by Raphaël Londeix 04 Nov '16

04 Nov '16

> > We encourage your participation in this review. At a minimum, kindly state: > - Whether you believe the library should be accepted into Boost > YES > * Conditions for acceptance > The interface used to spawn processes should be reworked. > - Your knowledge of the problem domain > I have implemented some process wrappers many times. I have used the last release of Boost.Process (0.5 I think?). > - What is your evaluation of the library's: > * Design > I think the similarity with the boost::thread api is a great choice. The lifetime of process is handled by small functors that will be called at specified times. I think is a very good design as it allows one to write small "plugins" in order to affect the setup or the tear down of a process. The integration with Boost.Asio follows the previous choice of using boost::thread as a reference, i.e. the child process is not the resource you read from/write to, you need some separate stream objects whose lifetime are tied to the child process: struct MyProcess { bp::async_pipe std_in; bp::async_pipe std_out; bp::async_pipe std_err; bp::child child; }; I haven't seen a way however to be asynchronously notified when a child exited, so I'm not sure how one would handle gracefully multiple async_read/write while the process could exit at any time. The choice of having a nice interface to spawn processes have been discussed already, but I still think that the library should aim to have the simplest and lowest level interface. IMO, C++ users do not need to have a nice and expressive syntax to spawn process, I cannot imagine a code base where many processes are launched at many places in the code. In other words, I think that either you rarely need to spawn a process (a hack for example), or your job is to spawn processes (a shell, a make clone, ...). In both cases, you will spawn processes in very few places in the code. Moreover, this interface style has an implication on build times, errors seen at build time and makes it hard to use in cases where your program needs to spawn processes based on runtime decisions. if one decided to implement a shell that supports redirections, pipes, environment modification and background jobs, they would certainly need to make runtime adjustments to the arguments given to child constructor. As of today, this has to be worked around by the user ; I think this should be the primary interface. A suggestion has been made to have a more idiomatic C++ construction, I would extend it with a specific options type: auto options = bp::options().args("gcc"); if (verbose) options.append_arg("-v"); if (ignore_errors) options.std_err.redirect(bp::null_device); bp::child child(io_service, std::move(options)); This way you make it impossible to modify the options after the child process creation. But that's just an idea :) * Implementation > The implementation is clear, but the support for the aforementioned constructor interface "leaks" into the implementation everywhere. As the previous version of Boost.Process, the different OS support is nicely separated and each stage of the process creation is clearly implemented in its own header. > * Documentation > The asynchronous section feels a bit short given the many possibilities the interface gives us. > * Tests > Didn't check > * Usefulness > I think it would be very useful to have something we can rely on instead of our own half baked implementations. > - Did you attempt to use the library? If so: > * Which compiler(s) > g++4.8 using c++11 > * What was the experience? Any problems? > I had many problems and decided to fallback on popen(). The first kind of problems were some compile errors. But the author kindly stated that I needed the HEAD of boost (which is not an option for me) but I found a workaround by not using some niceties of the interface: https://github.com/klemens-morgenstern/boost-process/issues/20 https://github.com/klemens-morgenstern/boost-process/issues/21 As said previously, for someone not used to boost.fusion, the errors are hard to read. The other problem that made me give up (temporarily) on using Boost.Process was the fact that asynchronous reads where unreliable when more than one process is spawned. https://github.com/klemens-morgenstern/boost-process/issues/22 This issue has been closed despite the fact that it is not fixed. - How much effort did you put into your evaluation of the review? > I'd say half a day counting this mail and the testing I made. Cheers, -- Raphaël Londeix http://hotgloupi.fr

2 1

[process] Formal Review
by Klaim - Joël Lamotte 03 Nov '16

03 Nov '16

Boost.Process Review ==================== ...At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance YES it should be accepted, though documentation need improvements. - Your knowledge of the problem domain I implemented naive and less naives ways to manage different processes in the past. I currently work on libraries which are all about multi-process communication and we have a poor-man's process management (launching, tracking, etc.) api that I have to maintain on Linux, Windows and MacOSX. I also have home projects which are organized as client-server with master-slave relationship, clients spawning servers and pinging them to keep processes alive mutually (using network communication). So basically, I implemented basic process management libraries, but I'm more a process management library user, in all my projects, paid or not. I have been exposed to a lot of problems related and solved a lot of them. I also used the last 2 Boost.Process versions proposed to Boost (though I voted no for these ones) but in cases where I just needed a cross-platform way to launch an arbitrary executable (no tracking nor communication). You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design The weird choice of variadic arguments in launching functions have been explained so I'm more at ease with it, though maybe ways to simplify it could be attemted in the future. I like that the design of boost::process::child follow, where it make sense, the design of std::thread. Both could be considered as execution resource, so it's fine to me that they share similar interface phylosophies of design (like spawning on construction and move-only). I would love it if there was a way (even slow) to track processes lifetime for processes that I don't have code for. Though it's ok for me if it's a future extension. I like the minimalism of the scope, though useful extensions could be added later. * Implementation I briefly eyescanned the code, looked more closely at the termination trigerriung code because of the discussion we had on termination reqest vs kill. I don't bother much about performance for this library as launching processes is rarely done in a tight high-performance loop. * Documentation I did a report of the documentation a few weeks or months ago, I do not know if changes have been made since. Anyway I think the documentation should have a part focused on explaining the concepts because even if most programmers knows what a process is, all related concepts (like what is the "environnement") are so specific to processes that they are often ignored as long as naive usage works. So as soon as the user need more specific usage, most, I believe, will not know what word to use to find the right concept. I think this library documentation should follow something similar to Boost.MSM which introduce to the basic concepts, though without walls of text. * Tests I didn't have time to try it yet in real applications, but so far didn't find any problem in basic usage. * Usefulness It is very useful for almost all my projects. - Did you attempt to use the library? YES If so: * Which compiler(s) Visual Studio 2015 for now. * What was the experience? Any problems? I only did minimal testing, nothing deep, no problems. - How much effort did you put into your evaluation of the review? Several hours diffused through several months. Joël Lamotte

1 0

[test] tests in master failing
by Aparna Kumta 03 Nov '16

03 Nov '16

I'm seeing the following error in the master branch compiling with Oracle Developer Studio. # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 287, in __init__ self.main() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 624, in main getattr(self,action_m)() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 589, in command_regression self.command_test() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 368, in command_test self.command_test_boost_build() File "/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_regression_src/regression.py", line 410, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/results/boost/bin.v2/libs/any/test/any_test.test' Looking at the bjam.log file I see: /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/kernel/modules.jam:107: in modules.call-in ERROR: rule "Jamfile</export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_root>.python-tag" unknown in module "Jamfile</export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_root>". /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/util/indirect.jam:98: in indirect.call /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/virtual-target.jam:455: in _adjust-name /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/virtual-target.jam:253: in abstract-file-target.__init__ /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/virtual-target.jam:561: in class(a)file-target.__init__ /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/kernel/class.jam:90: in class.new /export/home/sstrunk-tester/boost_regression/boost_regression_master/boost_intel-S2_cpp11/boost_bb/src/build/generators.jam:558: in generated-targets ... Has anyone else seen this? Thanks, Aparna

3 2

[filesystem] Move constructor from string_type
by danny kabrane 03 Nov '16

03 Nov '16

Hi all, boost::filesystem::path has 2 constructors from a string_type, one with a const reference and another one without const (wich I find troubling), but there's no constructor from a rvalue string_type. Is there something planned to add a move constructor from a string_type ? Regards Danny

2 1

[build] Annoying warnings from Asio, -isystem from bjam?
by Vinnie Falco 02 Nov '16

02 Nov '16

When I have "-Wunused-variable" I get these highly annoying warnings from boost/asio/error.hpp which I'm sure almost everyone has seen: boost_1_60_0/boost/asio/error.hpp:258:45: warning: ‘boost::asio::error::system_category’ defined but not used [-Wunused-variable] static const boost::system::error_category& system_category I don't want to disable the warning but I also don't want the false positives. Thankfully, clang and gcc have this wonderful option "-isystem" which lets you mark include paths as belonging to the system. This prevents warnings from being emitted that the programmer can do nothing about. How can I get Boost.Build to add the Boost library header search paths using "-isystem" so that gcc doesn't report warnings in Boost headers that I cannot do anything about? More detail here: http://stackoverflow.com/questions/1867065/how-to-suppress-gcc-warnings-fro… I've played around with <sysinclude> but can't seem to figure it out. Here's my Jamroot (my project builds on its own, without putting it in the Boost tree): https://github.com/vinniefalco/Beast/blob/master/Jamroot#L80 -- Follow me on Github: https://github.com/vinniefalco

2 2

[algorithm]Interface for search algorithms
by Зайцев Александр 02 Nov '16

02 Nov '16

1 0

[release] 1.63.0 closed for major changes
by Daniel James 02 Nov '16

02 Nov '16

Hi, The master branch is closed for major changes. In one week (9th Nov) it will be closing for the beta release. The full schedule is on the website: http://www.boost.org/development/ And if you haven't done so yet, please can you add your libraries' details to the release notes at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… Or email them to me, if you don't like writing quickbook.

1 0

Curiousity question
by Edward Diener 01 Nov '16

01 Nov '16

I would like to ask a design question for any Boost developers or anyone on this mailing list who might care to answer. You are designing or working on a library, perhaps for Boost, perhaps for fun, and part of the design of the library has some public functionality taking a shared pointer as input. You: 1) Use boost::shared_ptr 2) Use std::shared_ptr 3) Use both boost::shared_ptr and std::shared_ptr with the same functionality 4) Use neither, you roll your own shared pointer-like functionality 5) You don't lke shared pointers and use raw pointers instead I really am curious about this. I haven't put any limitation on your library or made any presumption on who your library is for, on purpose. Thanks for anyone answering !

13 53

[process] Formal Review starts today, 27 October
by Remi Chateauneu 31 Oct '16

31 Oct '16

Hi All, "Whether you believe the library should be accepted into Boost" It could be, but as some very important features are missinge, the implementation should be prepared from now on. "Your knowledge of the problem domain" About 20 yrs C++ development Linux and Windows. This library has a strong focus on the streaming which is quite rare and interesting. However, other very important features of multi-processing are missing should be planned: At least to ensure that, in the future, they can be added without breaking existing code. Example of these desired fatures are (Taken from my own needs) * List of subprocesses of a given process. * Get its parent pid (Already discussed). * Get the entire process tree of a machine. * It is very useful to be notified when a given process dies (unotify on Linux). * On windows, we have the feature e.startup_info.dwFlags = STARTF_RUNFULLSCREEN, which gives some control on the console, which Is very good. Could we have more documentation about it, and plans to have the same feature on Linux ? Generally speaking have some control on the process terminal if there is one. * Have some knowledge about users and user groups, as strings and integer identifiers: the concept is similar on Windows and Unix. * Have some control on process priority( Unix's nice command ) Indeed, many of these features are not portable, but most of time, developers use only a common core of features, which is quite enough. Maybe take inspiration from portable libraries such as Python psutil, which exposes a common interface for all operating systems. Interoperability: * It might be worth checking portability with other operating systems. BSD ? VMS ??? * Must ensure that this lib is interoperable with boost::interprocess (Concept of permissions might be worth using ?) * Does it build on pre-C++11 compilers ? Many projects are not able to upgrade to C++11 immediately and have to stick to previous C++ standard. Some critics (Nothing is perfect): * The merit of the ">" operator for optional arguments is to be visually similar to an indirection, but in the context of C++ programming, although elegant, it is I think confusing and could be mismatched with <> templates or comparisons. Creating a process is a not-so-frequent operation and we should not be afraid to be verbose and very clear, I believe. * Syntax ‘(bp::std_out & bp::std_err) > "output.txt"’ . Can we explain the exact difference with the syntax: ‘bp::std_out > "output.txt", bp::std_err > "output.txt"’’ * More comments in the code and examples please. * Examples async_io.cpp or arg.cpp do not build with boost 1.62: include\boost\process\detail\windows\compare_handles.hpp(24): error C2039: 'BY_HANDLE_FILE_INFORMATION_': is not a member of 'boost::detail::winapi' * ‘typedef basic_environment<wchar_t> wenvironment;’ : Is It really useful ?? POSIX getenv() only uses char. * Why is the class basic_environment so big, as it is basically a simple std::map< std::string, std::string > ? (Naïve question). Anyway, many congratulations for this very interesting work, which is definitely on the right direction. Regards

2 1

[gil] Some documentation links broken
by Edward Diener 31 Oct '16

31 Oct '16

In the documentation for Gil the links to the video tutorial, as well as the Information links on the left hand side of the initial page, are broken. Does anybody know if these links still exist anywhere ?

1 0

libstdc++ debug mode
by Robert Ramey 31 Oct '16

31 Oct '16

Back on May 2 2016 I made what I thought was an innocuous change to the serialization library build. I then forgot about it. I ran my tests and normal on my OSX set up for the compilers that I use there - clang and g++ 5.1 in various modes 03, 11 etc. Things seemed fine. I uploaded the develop branch as normal. Sometime later I discovered that all the gcc tests on linux platforms were failing with a segfault. Unfortunately time had passed and I couldn't run the tests myself so I never could figure out what the breaking change was. Lately I separated time to get to the bottom of this and in installed via Parallels ubuntu v 14 on my Mac as a guest operating system. After the usual back and forth getting stuff to work I was able to reproduce the problem. Running gdb indicated that things crashed with a call to boost::io::state_saver which led me to investigate THAT library which as it turned out is also failing all it's tests on the plaform. So thought I - no problem - all I have to do is to complain to the author of that library. But this didnt' workout a) I posted message and no one responded. b) I checked trac items and there was what seemed a related item. But it seemed a little hard to understand/fix and in any case, no one addressing it. I looked into just fixing it myself, but it looked to entail delving into the bowels of libstd++. So this dissuaded me as I have my own bowels to delve into. c) So I commented out references to boost::io::state_saver an ran some tests - and damn still failed. d) So I rolled back my source to the master dated 24 April 2016 and incrementally updated and ran some tests until I found the culprit. Needless to say, this is quite a tedious procedure. The issue seems to be that I added the following to the jamfile: <toolset>gcc:<define>_STLP_DEBUG <toolset>gcc:<define>_GLIBCXX_DEBUG The second adds a lot of checking. commenting this permitted tests to pass. Lesson of all this is: a) I'm thinking we should run all tests on the deelop branch with _GLIBCXX_DEBUG defined. That is, our jam files should contain?: <toolset>gcc:<variant>debug><define>_GLIBCXX_DEBUG b) it looks like when an error in libstd++ is encounted - things just segfault. I couldn't find the corresponding source in libstd++. GDB just bailed when I made a call to state_saver. c) boost::io::state_saver should be maintained. d) It would be helpful to be able to roll back the test matrix to any previous git version. That is, the results would be put into a database or datacube and we could scroll back and forth to see track down problems in test results. Robert Ramey

3 3

Review Manager needed for stacktrace library
by Antony Polukhin 27 Oct '16

27 Oct '16

Hello, Stacktrace is a C++98 library for storing and printing backtraces. Supports major platforms, does demangling, has API for accessing individual frames, supports hashing and comparison operators. Library: https://github.com/apolukhin/stacktrace Docs: http://apolukhin.github.io/stacktrace/index.html Anyone wishing to become the Review Manager for the library? -- Best regards, Antony Polukhin

8 21

[preprocessor] PR decision for Intel C++ 17 on up on Windows
by Edward Diener 27 Oct '16

27 Oct '16

I need some guidance from Boost developers in general. A PR has been issued for Boost PP which only affects Intel C++ 17 on up in Windows. I can ascertain that only this compiler in Windows is affectd by the PR. Needless to say I do not test this personally because it costs a decent amount of money to buy a license. Intel does graciously offer free licenses for Intel C++ on Linux for Boost developers and I have used it to test the compiler under Linux. Also there are no regression tests for Intel C++ on Windows in the 'develop' or 'master' regression test matrices. While the person who issued the PR ascertains that it fixes problems for Boost libraries he uses with Intel C++ 17 on Windows the nature of the PR is drastic enough that it could easily break other libraries if the changes in the PR does not correspond to Intel C++ preprocessing in all cases. So my quandary is what to do about the PR. The PR is at https://github.com/boostorg/preprocessor/pull/9#issuecomment-256741882. It is another one of these cases, like clang targeting VC++, where a compiler implementation on Windows wants to emulate the non-standard VC++ preprocessor but can't quite get it right ( as if emulating a broken preprocessor should ever be right ). Thoughts ? Ideas ? Suggestions ?

3 4

Boost odeint 1.62 link broken
by Daniel Duffy 27 Oct '16

27 Oct '16

________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Karsten Ahnert [karsten.ahnert(a)googlemail.com] Sent: 16 May 2016 15:08 To: boost(a)lists.boost.org Subject: Re: [boost] Boost 1.61.0 has been released > The Asio link http://www.boost.org/doc/libs/1_61_0/libs/asio/ is broken > (on http://www.boost.org/doc/libs/1_61_0/) I get ERR_TOO_MANY_REDIRECTS > with Chrome. The odeint link is also broken. I get "404 Not Found File "/home/www/live.boost.org/common/code/../../doc/archives/boost_1_61_0/libs/numeric/odeint/doc/html/index.html" not found. Unable to find file." Karsten _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[boost.process] Review
by Klemens Morgenstern 27 Oct '16

27 Oct '16

Boost.Process 0.6, as can be found here (https://github.com/klemens-morgenstern/boost-process) will be in review from October 27 to November 5. The review manager will be Antony Polukhin. Doc (http://klemens-morgenstern.github.io/process/) I really hope this library gets through the review, since boost (or C++ for that matter) really needs a process library. I would be really happy, if some of you could take the time to look into it - if you find any major issues, they might be addressed, before the actualy review. That would then increase the probability of the library getting accepted.

5 13

[release] 1.63.0 now closed for new libraries and breaking changes
by Daniel James 27 Oct '16

27 Oct '16

Hello all, The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week (2nd Nov) and closed for the beta in two weeks (9th Nov). Also, if you're ready, you can also add your libraries' changes to the release notes at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_63_0.q… thanks, Daniel

2 3

[fixed_point] First presentation from GSoC 2015 and more
by Christopher Kormanyos 25 Oct '16

25 Oct '16

Hello Boost developers, A partial implementation of fixed-point in a Boost-like style based on proposal N3352 is now available.This work is the result of developments from 2013-2016, including efforts from GSoC 2015. The source code is available at: fixed_point-masterPreliminary docs are available at: fixed_point-docWe are potentially interested in submitting this work for inclusion in Boost. We are now requesting comments and suggestions for improvements, corrections and any further test results if these become available.Some key library features include:* proper C++ header-only implementation * full numeric_limits and <cmath> functions * flexible template choice of split between resolution and range * automatic selection of underlying integral representation * portability and high efficiency for bare metal microcontrollers * interoperation with Boost.Math * seamless extension to high-precision using Boost.Multiprecision * extensive test suite Thank you for your consideration. Best regards,Christopher Kormanyos

7 22

[serialization] 2 blocking bugs
by alainm 25 Oct '16

25 Oct '16

Hi, My Boost.MPI builds are currently failing because of two blocking bugs in serialization (merge request 47 and 46). Could someone have a look please ? Thanks Alain

1 0

boost @ Meeting C++ 2016
by Jens Weller 24 Oct '16

24 Oct '16

Hello boost community, a short and final reminder, that the Meeting C++ conference is just a few weeks away! A few tickets are still available, here is the schedule: https://meetingcpp.com/index.php/schedule16.html The schedule also has the link to the student program and diversity tickets! Also there is still a few places available in the boost workshop with Boris Schäling and Michael Caisse. I plan to have a meetup for boost users in one of the breaks in the upper lounge, so that the boost communtiy is able to actually meet at Meeting C++! thanks, Jens Weller

1 0

Interest in chained relational operations
by Rahman Salim Zengin 24 Oct '16

24 Oct '16

Hi, The code in question is a simple chained comparison implementation. It works with any type If relational operators for that type is defined. https://github.com/rszengin/chain May some people find it useful?

4 4

predef: BOOST_COMP_MSVC defined for Gcc/Linux?
by Oliver Kowalke 24 Oct '16

24 Oct '16

Hi, test '#if defined(BOOST_COMP_MSVC)' evaluates to true with GCC on Linux. what I'm missing? Oliver

2 2

[interprocess] interprocess_condition blocks on notify_all if other process crashes
by Remi Chateauneu 22 Oct '16

22 Oct '16

When two processes share memory, and if one of them dies leaving a mutex in locked state, then the other process blocks on a notify using a interprocess_condition, stored in shared memory. This is described here: http://stackoverflow.com/questions/18240263/boost-interprocess-condition-bl… The reason is that this condition uses in general, a ipcdetail::spin_condition. Here is what it does in boost/interprocess/sync/interprocess_condition.hpp and boost/interprocess/sync/spin/condition.hpp : inline void spin_condition::notify(boost::uint32_t command) { //This mutex guarantees that no other thread can enter to the //do_timed_wait method logic, so that thread count will be //constant until the function writes a NOTIFY_ALL command. //It also guarantees that no other notification can be signaled //on this spin_condition before this one ends m_enter_mut.lock(); It locks an internal mutex, and if it is already locked and not unlocked by the crashed process, we are blocked. A fix is to replace lock() by: if( ! m_enter_mut.timed_lock(delay) ) throw an_exception(); A cleaner fix would be to derive a subclass from spin_condition to implement something like: bool derived_spin_condition::timed_notify(boost::uint32_t, ptime delay) What do you think ? Thanks.

2 1