- Boost - lists.preview.boost.org

[Review] Review results for Coroutines
by Hartmut Kaiser 24 Nov '12

24 Nov '12

All, The review for the Coroutines library written by Oliver Kowalke started September 3rd 2012, and ended on September 12th 2012. I counted 7 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Oliver Kowalke's Coroutines library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The Coroutines library offers enormous potential for programming regimes such as communications software and embedded systems design. Oliver selected a sensible granularity for his design. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. In particular, the separation of Coroutines from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. Some suggestion related to the API have been made during the review, most of which (if not all) have already been addressed. Oliver has a full list of things and works on integrating the suggestions. Here is a short list: - allow to specify the allocator to use for memory allocations inside the library - remove 'self' pointer and replace with TLS - add symmetric coroutines API - better support for generator functionality Naming ------ Some of the people participating in the discussions suggested not to use the abbreviated 'namespace coro', but to use the full 'namespace coroutines' instead. This again is not a precondition for acceptance. Documentation ------------- The consensus of almost everybody referring to the documentation was that it is terse but readable and sufficient. People suggested to integrate the docs of the old Coroutines library (written as an GSoC project by Giovanni P. Deretta) into the documentation of the reviewed library. I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://www.cct.lsu.edu/~hkaiser http://stellar.cct.lsu.edu http://boost-spirit.com

1 0

Re: [boost] Countertree
by Leo Goodstadt 23 Nov '12

23 Nov '12

> On Tue, 20 Nov 2012, Vadim Stadnik <vadimstdk(a)gmail.com> wrote: > > On Mon, Nov 19, 2012 at 9:02 PM, Leo Goodstadt <leo.goodstadt(a)llew.org.uk>wrote: > > 1) For counter trees, the median is just the N/2-th value in the > > counter tree, where K is the size of the tree. > > The Nth-percentile can be calculated similarly. > > A rolling median with a fixed size window requires there to be an > > insertion and deletion for each (most!) new value, so I am guessing > > it should run in O(N log K) time, where N = size of data, K = size of > > window > > > > IIUC, it is better to avoid modifying original data (size N), the rolling > window of size K can be represented by a multiset based on an augmented > tree. This method guarantees complexity of obtaining 1st median value for > O(K log K) operations, which is the cost of construction of the rolling > window, every subsequent median value can be obtained for O(log K) > operations, when the window rolls. This approach should be more efficient. > Oops. Careless editing made me mix up my Ks and Ns, hopeless confusing everyone. So given a large data set of size N and we want to calculate medians across a rolling window of size K, we only need to create a counter tree of size K (the window size). The median is the K/2 value in the tree. As you point out, the entire operation runs in O(N log K) time. All sensible approaches to calculating medians I can think of take O(N log K) time. The question comes down to what the constants are. The great advantage of a counter tree is that we are not limited to medians (the 50%ile value). We can collect for example, the values at 25%, 50%, and, 75%, and so on, at only marginally extra cost. I presume that most of the cost lies in balancing the tree after insertions/deletions and updating the counters. The only shortcut is the trivial optimisation that if the value entering the window is the same as the one being removed at the other end, then the median obviously stays the same. Leo

3 4

[coroutine] update for intel/clang
by Oliver Kowalke 23 Nov '12

23 Nov '12

The lib compiles with gcc, intel, clang (bug fixed), msvc and mingw (statically linked) on Windows. The fixed version of boost.coroutine is available at: http://ok73.funpic.de/boost-coroutine.zip. The documentation is updated too: http://ok73.funpic.de/boost/libs/coroutine/doc/html/index.html Oliver

1 0

Re: [boost] [website] bcp link broken
by Brian Wood 22 Nov '12

22 Nov '12

>>> bcp. Get taken nowhere. Any clues? TIA, >> >> Some googling found the page[*]. There, I read this: >> >> Copyright ? 2209 John Maddock >> >> Year 2209?! Great scott!!! Doc Emmett just called. He wants his DeLorean >> back. ;-) > > DeLorean? Man that's so last millenium :) > Maybe some are noticing a back to the future element in C++? -- Brian Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

[preprocessor] Maybe a improvement of BOOST_PP_IS_EMPTY
by Zhenghui Zhou 22 Nov '12

22 Nov '12

As I known, the undocument interface BOOST_PP_IS_EMPTY is not a general implementation to condider emptiness. There is a undefined behaviours when token concatenation return a invalid preprocessing token. Particularly, gcc restriction reports error. For example: #include <boost/preprocessor/ facilities/is_empty.hpp> BOOST_PP_IS_EMPTY() /* result: 1 */ BOOST_PP_IS_EMPTY(a) /* result: 0 */ BOOST_PP_IS_EMPTY(+a) /* error report here, for '+' cannot be pasted */ Here is a work around, it hasnot been tested enough, but does do under gcc. #define MY_IS_EMPTY(a) BOOST_PP_EQUAL(BOOST_PP_SEQ_ SIZE(MY_IS_EMPTY_II(MY_IS_EMPTY_I(a))), 2) #define MY_IS_EMPTY_I(a) (BOOST_PP_CAT(MY_IS_EMPTY_I_, BOOST_PP_SEQ_SIZE(a))) ) #define MY_IS_EMPTY_I_0 MY_IS_EMPTY_I_HELPER BOOST_PP_LPAREN() #define MY_IS_EMPTY_I_HELPER(a) )a( /* when a is empty, my may get more sequence elements of boost proprocessor */ #define MY_IS_EMPTY_II(a) BOOST_PP_CAT(MY_IS_EMPTY_II_, BOOST_PP_SEQ_SIZE(a)) ) #define MY_IS_EMPTY_II_1 ( #define MY_IS_EMPTY_II_2 ()( It uses a intermadiate result of BOOST_PP_SEQ_SIZE with wrong parameters, as: BOOST_PP_SEQ_SIZE(a) => 0 a ... I think it maybe better to allow any concatenation tokens in the language itselft. It's hard to avoid such thing when taking the preprocessor as a MPL. I just reported it on comp.std.c, https://groups.google.com/forum/#!topic/comp.std.c/7rgt8k6ILMM. There are more things and problems I did and I met. Hope for more response.

3 4

[website] bcp link broken
by Eric Niebler 22 Nov '12

22 Nov '12

Go here: <http://www.boost.org/doc/tools.html>. Click on the link to bcp. Get taken nowhere. Any clues? TIA, -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 4

[dynamic_bitset] expression template?
by Ben Coates 21 Nov '12

21 Nov '12

dynamic_bitset currently allocates temporary vectors for most operations, and all the allocating and deallocating can easily dominate the running time for a program that makes heavy use of them. You can work around some of it with careful use of named temporaries around loops but some operations like intersection of 3 sets ( (a & b & c).any() ) result in a lot of unwanted copies and allocations. I've had good results converting it to use expression templates for intermediary operations, with the outcome of being able to do arbitrary non-resizing operations without allocating. Is there any interest in changing the boost version to do this?

2 2

Should the clang, c++11 and libstdc++ configuration supported?
by Vicente J. Botet Escriba 21 Nov '12

21 Nov '12

Hi, clang compiler is not delivered with a C++11 standard library. When compiling on c++11 mode, some boost libraries (in particular, Boost.Thread, Boost.SmartPtr, Boost.Test) are expecting to have a C++11 standard library. This mean that the user needs to install the latest version of libc++. Could we state clearly in the release notes if the combination clang+ -std=c++11 + libstdc++ is not supported. Otherwise these libraries should update their code so that the user can use this combination. Best, Vicente

8 21

[stl_ext_adv] comparison with Boost.Container and string algorithms
by Vadim Stadnik 21 Nov '12

21 Nov '12

Hi all, In response to the previously made suggestion, I have added to the documentation the comparison of new proposed STL containers with Boost.Container. Please let me know if some of my statements concerning Boost.Container are incorrect, I will update the documentation. >From a user perspective an augmented array based B+ tree of the new library can be regarded as a segmented vector that offers several more efficient operations than std::vector: logarithmic time insertion, erasure, splice and split. One such data structure can support interfaces of all C++03 standard sequences and associative containers. This is why new containers offer a higher level of uniformity and generalization of the C++ standard containers. Unlike std::vector, the new array based containers do not have the problem of exponential storage growth and manual shrinking storage to the optimal capacity. The comparison section also includes simple tests of performance. One test shows the advantage of the wide set of efficient operations of new containers. None of the C++ standard and Boost containers can outperform new containers in the test with just two operations: move an iterator to a specified position and then insert a new element. The other test shows that new containers have good locality of reference. In sequential processing they perform much better than containers using dynamically allocated data structures. String algorithms The new sequence container that implements the union of interfaces of std::vector, std::list and std::deque is particularly beneficial for string algorithms. A container, such as std_ext_adv::sequence<char>, efficiently supports all main editing string operations: cut, copy, paste, delete, find, replace, etc. In terms of computational complexity this new container provides general and equally efficient support for both copy and move semantics operations. The move semantics functions splice() and split() can be used to replace inefficient copy semantics functions insert() and erase() to achieve significant performance improvements. The examples section and code shows how to concatenate two strings and extract a sub-string in logarithmic time using the move semantics functions. These operations do not require that user algorithms count moved characters. This functionality and efficiency are not possible with linked lists and basic search trees. The efficient calculation of statistical parameters and numerical integration in logarithmic time are the other practically important applications of the new containers. They are discussed in the examples section. Project (source code and documentation): https://github.com/vstadnik/stl_ext_adv_review Documentation: http://dl.dropbox.com/u/51041088/stl_ext_adv_review/doc/index.html Regards, Vadim Stadnik

1 0

Re: [boost] [Boost-build] [VxWorks] Updating boost/config/platform/vxworks.hpp for VxWorks 6.9
by Vicente J. Botet Escriba 20 Nov '12

20 Nov '12

Le 20/11/12 15:30, Brockamp, Peter a écrit : > Hello everybody, > > I'm new to the Boost.Build mailing list, so please forgive me any newbie > mistakes. I hope this is the right place for my post, if not please > redirect me to where it belongs! > I'm replied to the boost dev ML as most of the patches concern Boost.Config. > OK, some time ago I had to realize that the platform configuration for > VxWorks boost/config/platform/vxworks.hpp appears to be badly outdated > and doesn't work with the actual version 6.9. I started to modify this > platform header and after a while managed to get Boost compile and run > under VxWorks 6.9, at least as far as we use it here today. I could > offer to the community to update the existing header if this is desired > (I suppose it is). If so should I post the source code here or how to > proceed? Yep, a newbie question. You can start by creating a ticket on the Trac system https://svn.boost.org/trac/boost/newticket. You could add a patch associated with the ticket. > > My modifications surely aren't perfect/complete but it might be a fresh > start for this OS: > > - I have only tested it under RTP (Real Time Process) of VxWorks, not > DKM (Downloadable Kernel Module), due to lack of time. DKM has many > limitations compared to RTP, so this might cause problems! > > - Equally, due to time constraints, I tested GCC only, not the > diab-compiler, as we don't use it here. Same as above applies here, > problems might arise and I could not guarantee I might be able to fix > them. > > - And I tested x86 only, as we actually don't develop for ARM, etc. > > - I could test with V6.9 only, as we are not using the prior versions, > so maybe there will be other problems yet unknown. But at least I could > confirm that it is impossible to get Boost running under early versions > of VxWorks (V5.x and older). These versions are lacking a couple of > library functions required by Boost, they come with a library which is > partially non-ANSI-conforming (especially the STL) and the compiler (GCC > 2.96) is outdated beyond believe and lacks some functionality (mainly > template stuff) needed by Boost. So some OS-version checking scheme > would have to be added to vxworks.hpp, bailing out in case of obsolete, > unsupported versions. > > - A support guy from WRS (Wind River System) mentioned that they are > thinking of including Boost into their OS, so they might do some > adaption work in the future. But until now it doesn't appear to me > there's much activity from WRS, that's why I decided to offer what I > have done so far. > > - When compiling Boost for VxWorks I didn't use the build-system, as > VxWorks does a cross compile for the destination platform and I didn't > manage to figure out how to auto build this. Instead I manually pulled > all of Boost's files into a Workbench Project (Workbench is the eclipse > based IDE of VxWorks). So there would be some work left to get this up & > running as well. > > - My work is based mainly on modifying and supplementing most parts of > vxworks.hpp. Anyway, during the tests I did I stumbled upon some > problems in other files, e. g. caused by missing #ifdef's for VxWorks, > and even errors in a few of Boost's files, which I fixed as well. Should > all these fixes be posted here, or what's the right way to do it? > > > So, if you see some potential use in what I have done, despite the > incompleteness pictured above, please someone responsible mail me with > further instructions. > Best, Vicente

1 0