November 2014 - Boost-users - lists.preview.boost.org

boost MSM
by Raj Sambasivan 10 Dec '14

10 Dec '14

Hi Christophe, I have been using boost msm, i have two state machines each with around 30 transitions / 4 regions , no submachine etc for now... it perfectly fits the bill on what im trying to do, thanks for the great library, one issue i face is ,the debug build takes for ever to compile and the size is very big (the optimized one with no debug symbol compiles pretty fast) and when errors happens the compiler (template barf) goes for pages and pages .. any hints on this please? thanks -raj

4 5

[Boost.Test] unexpected behavior after std::system(...)
by contini.mailing＠gmail.com 09 Dec '14

09 Dec '14

Hi, I'm using boost 1.57 with gcc 4.7.2 on a debian wheezy. I'm testing an external program that has a non-zero return code and i'm experiencing an unexpected behavior of Boost.Test library. If the test below is linked statically (commenting the first line of course) everything works fine and all the three tests are executed. If the test below is linked dynamically i get the following output: test0 test1 unknown location(0): fatal error in "test1": child has exited; pid: 32314; uid: 1000; exit value: 4 (here program hangs forever and the third test is never executed) Defining the environment variable BOOST_TEST_CATCH_SYSTEM_ERRORS=No circumvents the problem. But i don't want to define it on all of the team member's computers and test machines. This can be considered a boost bug? #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MODULE test_module #define BOOST_TEST_IGNORE_NON_ZERO_CHILD_CODE #include <boost/test/unit_test.hpp> #include <stdlib.h> BOOST_AUTO_TEST_CASE( test0 ) { std::system("echo \"test0\";exit 0;"); } BOOST_AUTO_TEST_CASE( test1 ) { std::system("echo \"test1\";exit 1;"); } BOOST_AUTO_TEST_CASE( test2 ) { std::system("echo \"test2\";exit 2;"); } Any help is appreciated.

2 1

[Boost.SIMD] Interest in library
by dariomt＠gmail.com 05 Dec '14

05 Dec '14

Hi, I'm interested in trying out Boost.SIMD. Where can I download the latest stable version? Any idea when it might get proposed for Boost review? I think it would be beneficial if it is added to the Boost Incubator until then. Also, in http://meetingcpp.com/tl_files/mcpp/slides/12/simd.pdf slide 36 I see mention of a vectorized Thomas Tri-diagonal Solver. I thought the data dependency made the algorithm unfeasible for vectorization, so I'm *very* interested to learn how Boost.SIMD helps in this case. Is there more information available about this? Thanks for working in a library that shows a lot of potential.

4 3

Fusion Move Semantics
by Ovanes Markarian 04 Dec '14

04 Dec '14

Hi! I would like to ask does fusion supports move semantics, or are all the values going to get copied. I use C++11 (clang with libstdcxx) and boost 1.54 (but can upgrade). In my use case I have boost::fusion::map and was wondering, that in case of moving of that map, is it going to forward the move call to contained values or not. Many thanks for help, Ovanes

3 2

Error "Used Uninitialized" in boyer_myrvold_impl.hpp
by wanglurg 02 Dec '14

02 Dec '14

Hi, guys, I'm a new boost graph library user. I met an error when using boyer_myrvold_planar_test() function in Boost_1_55_0 to generate the kuratowski subgraph. Error message is listed as follows: ./boost/graph/planar_detail/boyer_myrvold_impl.hpp:1545:11 error: 'z' may be used uninitialized in this function. I added a "Wno-maybe-uninitialized" flag to Makefile to remove this error temporarily, but it's not a good method. I'm looking for a better way to fix this. Does anyone encounter the same case? Best regards, Lu Wang -- View this message in context: http://boost.2283326.n4.nabble.com/Error-Used-Uninitialized-in-boyer-myrvol… Sent from the Boost - Users mailing list archive at Nabble.com.

2 2

Reverse for loop with boost::adaptors::reverse crashes
by Filip Konvička 28 Nov '14

28 Nov '14

Hi, I was trying to replace BOOST_REVERSE_FOREACH with the standard range-based for loop. #include <boost/range/adaptor/reversed.hpp> #include <boost/foreach.hpp> #include <vector> #include <iostream> std::vector<int> getv() { return std::vector<int>{1,2,3}; } int main(int argc, char* argv[]) { // works fine: BOOST_REVERSE_FOREACH(int i, getv()) std::cout << i << std::endl; // crashes: for(int i : boost::adaptors::reverse(getv())) std::cout << i << std::endl; return 0; } Maybe this is basic C++ I should understand; it looks like the temporary vector returned by getv() gets destroyed in the 2nd loop too soon. I was wondering whether the adaptor could warn me that I'm using it in a wrong way (the code looks so nice and compiles cleanly...). Thanks, Filip

5 9

Boost.Log: default sink auto flush
by Mathias Gaunard 27 Nov '14

27 Nov '14

It would be very useful if the default sink could be made to auto flush. Is there any way to do this? I do not want to add a new sink, since the default sink cannot be replaced.

1 0

Unable to build universal binary on Mac OS X
by Kevin Molcard 27 Nov '14

27 Nov '14

Hi all, I am trying to compile boost on Mac OS X 10.9.5 for 32 and 64 bit. I am using the following command: ./b2 link=static threading=multi architecture=x86 address-model=32_64 I get the following error message: darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/link-static/threading-multi/../src/tr1/pch.hpp.gch clang: error: cannot use 'precompiled-header' output with multiple -arch options "g++" -x c++-header -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -arch i386 -arch x86_64 -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED -DNDEBUG -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/link-static/threading-multi/../src/tr1/pch.hpp.gch" "libs/math/build/../src/tr1/pch.hpp" ...failed darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-x86/link-static/threading-multi/../src/tr1/pch.hpp.gch... Then 144 targets are skipped. Does anyone knows how to fix this? Thanks in advance Kevin

2 2

[review] [sort] Sort library review manager results
by Edward Diener 27 Nov '14

27 Nov '14

This is the results from the recent review of the Sort library of Steven Ross. First I would like to thank all those who made comments during the review, whether or not they officially gave a final Yes or No vote to whether the Sort library should be accepted as a Boost library. This list includes: Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus, Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs (M.A.) van den Berg Dupuis Etienne, and Frank Gennari If I have missed anyone I do apologize. Secondly I would like to thank Steven Ross for patiently answering all of the review comments to the best of his ability. My tally of Yes and No votes for acceptance are: Yes votes (5) : Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ), Frank Gennari, Phil Endecott, Paul Bristow. No votes (3) : Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin I believe the condtional Yes vote from Julian Gonggrijp was completely met in the discussions of issues with Steven Ross and the conditional Yes vote from Niall Douglas was almost completely met in the discussion with Steven Ross about the issues mentioned, and enough to maintain his Yes vote. I want to also mention that the conditional No vote by Adam Walling has an implied Yes vote to it if the Sort library were one among other sort implementations. Since my final decision is not entirely based on the Yes and No votes I want to adumbrate some of the major issues brought up by the review without necessarily focussing on every one of the people who brought them up initially, as well as my own reactions to them as Review Manager. 1) The first major issue was whether a library whose basic merit lies in its algorithm and its speed/space constraints needs better theoretical backing. A number of reviewers discussed this after it was brought up. I tend to agree with reviewers that while the best theoretical basis is always desirable, it is not necessary for a Boost library whose empirical evidence can be and has been measured by its implementor and can be measured by any user. Furthermore Steven Ross has provided an extensive discussion in his documentation, as well as his original paper, about the theoretical merits of his technique. While much of this discussion is probably beyond the understanding of any but sorting experts and afficionados enough of it adequately explains the basic ideas behind SpreadSort for those who understand and have knowledge of basic sorting ideas and popular sorting techniques. 2) An important issue is the need for the Sorting library to provide extensive timing charts/tables comparing SpreadSort to at least std::sort ( and possibly other popular mainstream sorts ) with both different numbers of sort keys and different initial unsorted distributions. Steven Ross has been providing these charts/tables in the 'develop' branch of the library. 3) Connected to the previous issue is that a number of reviewers asked for better documentation on the conditions in which SpreadSort will show a marked improvement in speed compared to std::sort, as well as any condition(s) where SpreadSort performs worse than std::sort. While Steven Ross has explained that generally SpreadSort will fall back to using std::sort for some cases ( low N ), I too feel that the documentation needs to be more extensive for the average user in attempting to delineate the conditions where SpreadSort works best. 4) A really important issue discussed by a number of reviewers involves the creation of a synthetic radix, where most users of sorting algorithm are used to comparison based sorting functors. While the documentation provides information on the various individual sorts, as well as examples, I also feel that a discussion in the documentation of how to use SpreadSort when sorting structs/classes with multiple keys of different types would be invaluable. In other words, what and if are the common techniques for using SpreadSort with complicated keys which, when using comparison-based sorting, can be represented fairly easily be a functor. 5) Niall Douglas brought up the issue of exception guarantees when using SpreadSort, and I concur. The documentation should be stronger specifying what happens during the sorting algorithms if an exception occurs and/or does the sorting algorithm itself ever throw any exceptions and, if so, under what conditions. Steven Ross mentioned that he is adding exception guarantee information to his docs. 6) Many reviewers did not like the idea that the library should be called Sort when it is basically implementing a single sorting algorithm called SpreadSort. Alternate suggestions are: a) The library should be called SpreadSort. b) The library can be called Sort only if other sorting algorithms are added to it. c) The library can be called Sort with the proviso that it serves as a general library for sorting algorithms potentially added to it in the future. d) The library should be part of the Boost Algorithm library. Steven Ross mentioned other potential sorting implementations as part of the Sort library, under that general name, but all providing a good deal of extra work. These included a copy-based stable sorting algorithm, an LSD radix sorting, and an OpenMP based parallel implementation. Other reviewers mentioned some of the same types of sorting implementations and a few reviewers remarked that they also have created sorting implementations of their own. While I will give my own view at the end, I would like to mention here that I strongly believe that each sorting implementation needs to be reviewed separately for acceptance into Boost and never automatically added to a general library, whether it be called Sort or Algorithm or whatever. 7) Random issues brought up in comments I will mention, which have importance but which I do not believe are absolutely intrinsic yet still might be considered. a) C++11 techniques in general and inline namespaces in particular. b) A version that can work with less than random access. c) Optimizations for small sets of data ( Steven Ross has already addressed this to an extent in the 'developer' branch of the library ). d) Possible documentation of using SpreadSort as a subsort for parallel sorting techniques and possible discusion in the docs about SpreadSort and parallel sorts. e) General O() information in docs. f) SpreadSort examples hoisted directly into docs using Quickbook technique and updating the Spreadort docs to use Quickbook. Review Result: Based on the voting for acceptance or not, based on the discussions during the review period, and based on Steven Ross's responses, I have decided that Steven Ross's library should be accepted into Boost. My main reason for my decision, aside from the votes and comments and specific issues discussed, is twofold: 1) There is a general consensus that Steven Ross has an excellent understanding of sorting techniques and algorithms and will support and refine his library for the benefit of programmers. 2) The empirical tests show that SpreadSort offers an improvement over std::sort, significantly in the area of large data sets, and this could be a major benefit to programmers. I do not know if the review manager has a say in this but based on the remarks of the reviewers I would like to see the library as accepted be named 'SpreadSort' rather than just 'Sort'. I do think that Boost can have a library called 'Sort' but I agree with the general consensus that a 'Sort' library needs more than one type of sorting algorithm. I would like to see other people, who mentioned in the reviews/comments that they have their own sorting implementation, also submit their own implementations to Boost and, if this happens and they are accepted, I can see combining them with 'SpreadSort' into a general Boost sorting library called 'Sort' in the future.

1 0

Boost not compiling with arm-cross-compiler
by ustulation 27 Nov '14

27 Nov '14

{Ubuntu 14.04 64 bits, arm-g++ compiler 4.9 one that comes with google's ndk r10c) (The compiler has --sysroot pointing to platform android-14, and -march=armv7-a) on using arm cross-compiler for compiling boost I get the following error in "*socket_ops.ipp*": *<1> for all function (templates) of this type:* template <typename SockLenType> inline int call_getsockname(SockLenType msghdr::*, socket_type s, socket_addr_type* addr, std::size_t* addrlen) { SockLenType tmp_addrlen = (SockLenType)*addrlen; int result = ::getsockname(s, addr, &tmp_addrlen); *addrlen = (std::size_t)tmp_addrlen; return result; } /some-path/thirdparty/boost/boost_1_55_0_Android/boost/asio/detail/impl/socket_ops.ipp:1639: error: invalid conversion from 'int*' to 'socklen_t* {aka unsigned int*}' [-fpermissive] int result = ::getsockname(s, addr, &tmp_addrlen); ^ On changing the line to: int result = ::getsockname(s, addr, (socklen_t*)tmp_addrlen); it compiles fine ofcourse but i don't know if this is what is to be done. *<2> And in "mapped_region.hpp": /some-path/thirdparty/boost/boost_1_55_0_Android/boost/interprocess/mapped_region.hpp:49: error: sys/shm.h: No such file or directory # include <sys/shm.h> //System V shared memory... ^ * and points to: # if defined(BOOST_INTERPROCESS_XSI_SHARED_MEMORY_OBJECTS) # include <sys/shm.h> //System V shared memory... # endif in that file. Here are the flags in my user-config.jam file: using gcc : android : @AndroidNDKSrcDir@/bin/arm-linux-androideabi-g++ : <archiver>@AndroidNDKSrcDir@/bin/arm-linux-androideabi-ar <compileflags>-fexceptions <compileflags>-frtti <compileflags>-fPIC <compileflags>-std=c++11 <compileflags>-ffunction-sections <compileflags>-funwind-tables <compileflags>-D__ARM_ARCH_5__ <compileflags>-D__ARM_ARCH_5T__ <compileflags>-D__ARM_ARCH_5E__ <compileflags>-D__ARM_ARCH_5TE__ <compileflags>-Wno-psabi <compileflags>-march=armv5te <compileflags>-mtune=xscale <compileflags>-msoft-float <compileflags>-mthumb <compileflags>-Os <compileflags>-fomit-frame-pointer <compileflags>-fno-strict-aliasing <compileflags>-finline-limit=64 <compileflags>-I@AndroidNDKSrcDir@/include/c++/4.9 <compileflags>-Wa,--noexecstack <compileflags>-DANDROID <compileflags>-D__ANDROID__ <compileflags>-DNDEBUG <compileflags>-O2 <compileflags>-g <compileflags>-I@AndroidNDKSrcDir@/sysroot/usr/include <architecture>arm <compileflags>-fvisibility=hidden <compileflags>-fvisibility-inlines-hidden <compileflags>-fdata-sections <cxxflags>-D__arm__ <cxxflags>-D_REENTRANT <cxxflags>-D_GLIBCXX__PTHREADS ; *What is the way forward for those two errors - <1> and <2> above ?* -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-not-compiling-with-arm-cross-compi… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1