- Boost - lists.boost.org

[Coroutine] Back to the caller
by Mikhail Strelnikov 18 Sep '15

18 Sep '15

Hi, I have an issue after switching from Boost.Coroutine to Boost.Coroutine2 - nested coroutine switches to its creator - not to the caller. Here is the code - http://codepad.org/WGNs0N7F There are two coroutines (1st coroutine starts, makes some progress, then spawns 2nd coroutine. But 1st coroutine knows nothing about 2nd and does not communicate with it - main thread does). With Boost.Coroutine it works as expected and outputs: g1g1g1g1g2g1g2g1g2g1g2g1g2g1g2g1 leaving coroutine 1 g2g2g2g2 leaving coroutine 2 Here you can see that 1st coroutine exits but 2nd keeps working normally. And control from coroutines is returned back to the caller (g - caller, 1 and 2 - coroutines). But with Boost.Coroutine2 it outputs: g1g1g1g1g21g1g21g1g1g21 leaving coroutine 1 assertion failed : (false) && ("pull_coroutine is complete") Here you can see that when caller (g) calls 2nd coroutine, it does not yield back to caller, but instead switches to 1st coroutine ("g21" in output).Then it terminates on assert "pull_coroutine is complete". Is it a bug of Boost.Coroutine2? If not, how can I change this code to work equally for Boost.Coroutine and Boost.Coroutine2? Thanks! P.S. What is the reason of boost::coroutines2::coroutine<void>::pull_type not having default constructor? It is still possible to have an "empty" pull_type, but it is painful process.

2 6

Interest in algorithm for arithmetic mean of integers
by Matt Calabrese 17 Sep '15

17 Sep '15

AFAICT the only function for calculating arithmetic mean in boost is in the accumulators library and it's not really appropriate for integral types. In practice, properly calculating the mean for a range (especially a range that's only an input range but not a forward range) is surprisingly tricky to do in a way that avoids overflow and provides an exact result. I have a couple of solutions, including one that works for input ranges. Is this something that people would find useful? Is there a similar algorithm already implemented in boost that I'm not aware of? The approach I've taken yields an exact result as a mixed number and should work without overflow (assuming only that the range's size is able to be represented by its difference type). I believe the implementation that works for input ranges could theoretically be adapted to work with Boost.Accumulators, though I'm admittedly not too familiar with the library. -- -Matt Calabrese

5 10

integrating NaCl support into boost
by Konstantin Ivlev 17 Sep '15

17 Sep '15

Hi boost community, some introdution: NaCl (Google NativeClient, https://developer.chrome.com/native-client) - open-source technology authored by Google Inc. providing way to run native code inside web-browser in portable and secure manner. NaCl provides posix-like environment, and supports newlib and glibc standard libraries. currently NaCl is supported by Google Chrome web-browser, and range of applications and software libraries are ported to NaCl (include zlib, quake, etc.). how about integrating NaCl support patches into the boost main-line (trunk/master), I am talking about these NaCl ports patches from Google: https://chromium.googlesource.com/external/naclports/+/master/ports/boost (I actually have a bit more correct patches that allow to compile boost 1.59 for NaCl platforms, while Google patches are still for old version 1.55). some details about patches and which boost areas are covered by patches: - boost/config - common setup for NaCl - boost/cstdint - small change to expose boost::uintptr_t/boost::intptr_t for NaCl, similarly to how it was done to other compilers - buitin.jam and gcc.jam - introduced new os-name for NaCl, in order to properly setup threading libraries (NaCl has pthread but no rt, just like BSD) - boost/system/errorcode - oddball version of strerror_r (just like cygwin), also ENOTRECOVERABLE & EOWNERDEAD errno codes are not supported by PNaCl - boost/log/light_rw_mutex - not supported on NaCl note that boost build is incomplete - certain libraries are not (yet) ported to NaCl, because of platform-specific stuff like file/network I/O : - context - coroutine - coruutine2 - log - filesystem - test - timer - wave not sure if it's OK for start, or all boost libraries should be ported together in order to process further. I would be grateful to hear suggestion about how to process with it, e.g. which actions should I take to make it really happen. I personally suppose making boost to officially support more platforms will make boost even more popular and allow more developers to use it and port their applications to other platforms. I look forward to hearing from you soon. yours sincerely, Konstantin

4 5

Windows Phone and Visual Studio 2015
by Vladimir Prus 17 Sep '15

17 Sep '15

Folks, did anybody had success building Boost for Windows Phone using Visual Studio 2015 (aka 14.0)? We have Boost.Build code to do so, but it tries to find vcvarsphoneall.bat script, and some other similarly named scripts, that I don't seem to have anywhere, despite been able to build WP app from the IDE. Has anybody solved this? Thanks, Volodya

1 1

[predef] BOOST_ARCH_BITS_* feature request
by Antony Polukhin 16 Sep '15

16 Sep '15

Hi, It looks like for low-level programming following macro could be really useful: BOOST_ARCH_BITS_64 BOOST_ARCH_BITS_32 BOOST_ARCH_BITS_16 ? Predef also missing BOOST_ARCH_ARM_64, BOOST_ARCH_PPC_64. Boost.DLL really needs those macro for detecting bit's dependent elf/macho/pe structures layout. Is it possible to add them? -- Best regards, Antony Polukhin

4 4

Copyright-less licence references
by Gennadiy Rozental 16 Sep '15

16 Sep '15

Hi, I suggest we should drop "Copyright Joe Coder 20xx" from all our files. My reasons: * git/svn history provides much better copyright attribution. Each developer has a copyright on lines authored. As it is these copyright disclaimers are very frequently wrong. * I am never clear what this line really mean. Copyright Joe Coder 2010 - does this mean Joe has copyright up to 2010, starting 2010 or only in 2010? Should one keep updating these disclaimers every January? * For libraries which are maintained by multiple developers and/or which were moved from one maintainer to another maintainer - these disclaimers either wrong or pain to maintain. * these are just a clutter with no real value IMO we should just keep licence reference and that's it: // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) Gennadiy

12 38

Determining interest in container with efficient random access insert and erase
by Chris Clearwater 16 Sep '15

16 Sep '15

Greetings, I have written a library with the intention of submitting it to Boost.Container. My container implements O(log n) random access insert/erase and has a strong focus on performance while supporting the interfaces of the standard library sequence types. An example application would be the character buffer of a text editor. Useful links: - Source code: https://github.com/det/segmented_tree_seq - Documentation: http://det.github.io/segmented_tree_seq/ - Benchmarks: https://github.com/det/segmented_tree_seq/tree/benchmarks Any feedback is greatly appreciated.

14 28

BOOST_PP array extension proposal
by Antoine Leblanc 14 Sep '15

14 Sep '15

Hello to all of you! A few years ago, I've developped a small extension to BOOST_PP that adds a few functions to it. Namely: * ARRAY_CAT, which concatenates two BOOST_PP arrays; * ARRAY_LOWER_BOUND, which finds the index of the lower bound of an item in a given array of numerical values; * ARRAY_SORT, which sorts the given array of numerical values; * ARRAY_SORT_U, which sorts the given array and remove duplicates. I'm not sure it'd be worth adding to BOOST_PP; but if you think it might be, I'd be happy to submit a merge request. The code is rather small and can be browsed at https://github.com/nicuveo/TOOLS_PP Any suggestion or input is welcome. Thanks for your time! -- Antoine Leblanc

6 34

1.59 release notes don't mention new property_tree::json_parser
by Jonathan Wakely 14 Sep '15

14 Sep '15

The commit logs say: TL;DR: The new parser fixes long-standing bugs and has full Unicode support, but removes non-standard extensions of the old parser, which could break code: - String concatenation: the old parser concatenated adjacent string literals like C does. - Comments: the old parser supported C and C++-style comments. JSON doesn't allow comments. Removing support for comments did break something. Unfortunately there was no sign of this in the release notes, so I had to debug it the hard way (in code that swallowed the exception from the parser - gah!) and only found the commit message once I already knew what the problem was. </rant>

4 5

[type_traits] New version in master
by John Maddock 14 Sep '15

14 Sep '15

Just a quick heads up that the new version of type_traits is now in master, if there are any issues please do shout, John.

5 7