June 2016 - Boost-users - lists.boost.org

Boost + Android NDK r11 + Clang
by Robert Dailey 23 Jun '16

23 Jun '16

How can I cross-compile static boost libraries for Clang in Android NDK r11 (arm) along with LLVM C++ (static)? Thanks in advance for detailed instructions

1 0

[iostreams] use of gzip_compressor with strings
by Boncek, John 23 Jun '16

23 Jun '16

I need to do some in-memory manipulation of strings, including compression to gzip format. I am new to the use of Boost and to the use of gzip. I found the following snippet on the Internet, compressing a std::string and producing a new std::string as output. This implies that gzip_compressor never produces a null byte in its output but the gzip_compressor documentation doesn't say that and my search of the underlying library zlib documentation doesn't say anything like that either. So is this a correct use? std::string compress(const std::string& data) { namespace bio = boost::iostreams; std::stringstream compressed; std::stringstream origin(data); bio::filtering_streambuf<bio::input> out; out.push(bio::gzip_compressor(bio::gzip_params(bio::gzip::best_compression))); out.push(origin); bio::copy(out, compressed); return compressed.str(); } Thanks, John Boncek

2 2

[Context] Console output problem under Cygwin
by Andrew C 23 Jun '16

23 Jun '16

Hi! Boost.Context examples (libs\context\example\v2) behave strangely under Cygwin/GCC-5.4.0. The problem is that all of the example applications output nothing to console. For example, jump_void.exe just ends at first "std::cout" command in execution context without any crash. This is the command line arguments I use to build both Boost.Context library and examples: b2.exe variant=debug link=static cxxflags="-std=c++14 -Wall -pedantic -D_GNU_SOURCE" Does anyone else ever met such a problem? Could it be a compiler bug or Boost.Context defect? Note: Under MinGW/GCC-4.9.3 all works OK. Thanks!

1 0

[polygon] get_trapezoids not reporting holes?
by David Thompson 22 Jun '16

22 Jun '16

Hi all, I am having trouble with boost::polygon: when get_trapezoids is called on a polygon_set_data containing a polygon_with_holes_data, it returns trapezoids covering the outer loop but that cover the hole (i.e., the hole is being ignored). A small example is below to demonstrate. I've tried with boost 1.60, 1.55, and 1.50. Am I doing something wrong? Thanks, David #include "boost/polygon/polygon.hpp" #include <vector> namespace poly = boost::polygon; typedef long long Coord; typedef poly::point_data<Coord> Point; Coord outerPts[] = { -37205784000000LL, -22528321200000LL, -20252740200000LL, -40391736000000LL, 19228717200000LL, -39708900000000LL, 37774737000000LL, 32882157000000LL, -37205784000000LL, -22528321200000LL, }; Coord innerPts[] = { -8808676800000LL, -4351000500000LL, 29799924000000LL, 21288613500000LL, 8185023000000LL, -10611816600000LL, -8808676800000LL, -4351000500000LL, }; template<typename T> void liftPt(double x[2], const T& pt, double sf) { x[0] = sf * pt.x(); x[1] = sf * pt.y(); } template<typename T> void print_polyarray(const std::string& msg, T& parr, double scale, double iscale) { std::cout << msg << " has " << parr.size() << " polygons\n"; std::vector<poly::polygon_data<Coord> >::const_iterator pit; int pp = 0; for (pit = parr.begin(); pit != parr.end(); ++pit, ++pp) { poly::polygon_data<Coord>::iterator_type pcit; std::cout << " Polygon " << pp << " has " << pit->size() << " points\n"; double p0[2]; for (pcit = poly::begin_points(*pit); pcit != poly::end_points(*pit); ++pcit) { liftPt(p0, *pcit, iscale); std::cout << " " << p0[0] << " " << p0[1] << "\n"; } std::cout << "--\n"; } } int main() { const double scale = 2.31e13; const double iscale = 1./2.31e13; poly::polygon_with_holes_data<Coord> pface; std::vector<poly::polygon_data<Coord> > holes; poly::polygon_data<Coord> loop; std::vector<Point> polypts1; for (unsigned ii = 0; ii < sizeof(outerPts)/sizeof(outerPts[0])/2; ++ii) { polypts1.push_back(Point(outerPts[2*ii], outerPts[2*ii + 1])); } pface.set(polypts1.begin(), polypts1.end()); std::vector<Point> polypts2; for (unsigned ii = 0; ii < sizeof(innerPts)/sizeof(innerPts[0])/2; ++ii) { polypts2.push_back(Point(innerPts[2*ii], innerPts[2*ii + 1])); } loop.set(polypts2.rbegin(), polypts2.rend()); holes.push_back(loop); pface.set_holes(holes.begin(), holes.end()); Point holecenter( 9725423400000LL, 2108598800000LL); Point nonholepnt(37774730000000LL, 32882150000000LL); // ^^ Compare to 37774737000000LL, 32882157000000LL, which is a vertex in outerPts. std::cout << "Polygon has " << pface.size() << " vertices and " << pface.size_holes() << " holes\n"; std::cout << "Winding is " << (poly::winding(pface) == poly::CLOCKWISE ? "cw" : "ccw") << "\n"; std::cout << "Contains hole center? " << (poly::contains(pface, holecenter) ? "Y" : "N") << "\n"; std::cout << "Contains point it should? " << (poly::contains(pface, nonholepnt) ? "Y" : "N") << "\n"; // The above demonstrates that pface appears to be a valid polygon with a hole. // However, now when we ask for trapezoids, no hole is provided: // Add pface to polys so we can get trapezoids: poly::polygon_set_data<Coord> polys; std::vector<poly::polygon_data<Coord> > parr; polys.insert(pface); polys.get(parr); // This prints that parr (and thus polys) contains 0 polygons, which seems wrong: print_polyarray("Original polygon set", parr, scale, iscale); polys.get_trapezoids(parr); // This prints 2 polygons that form only the outer boundary, which seems wrong: print_polyarray("Tessellation ", parr, scale, iscale); return 0; }

1 0

[boost] Checking interest in stacktrace library
by Antony Polukhin 22 Jun '16

22 Jun '16

Hi, I've got some prototype for getting stack traces: https://github.com/apolukhin/stacktrace It's design is based on the idea that class for stacktrace must be fully noexcept, without dynamic allocations in constructors and as simple as possible. Is there interest in it? What functionality would you like to have in it? -- Best regards, Antony Polukhin

7 12

Coroutine jump_fcontext crash (Boost 1.61)
by Jason Mancini 22 Jun '16

22 Jun '16

Hello, Starting with Boost 1.61, if -DBOOST_USE_VALGRIND=1 is set, then the Coroutine sample from boost docs crashes on first stack switch. Is this a known issue? (We're using GCC 6.1 on 64-bit Linux.) Not posting a code sample, it's literally the exact one from the Coroutine web page. Compile with the define, then run. We have Valgrind 3.10.1 installed. [Curiously, the Context code sample runs fine.] I am suspecting a missing snippet on the Coroutine side that affects stack_context structure size. Thanks! Jason # gdb ./a.out ... SIGSEGV, Segmentation fault. (gdb) bt #0 0x00002aaaaaab3ec0 in jump_fcontext () from .../lib/libboost_context.so.1.61.0 (gdb)

3 8

Re: [Boost-users] Suggestion for boost::dll:import_alias<>() or boost::dll::import<>()
by Leo Carreon 19 Jun '16

19 Jun '16

Sorry, I figured out how to use the search capability. I was misinformed because the documentation did not include the possible values for boost::dll::load_mode which I discovered by needing to have a look in the source code. From: Leo Carreon Sent: Sunday, June 19, 2016 1:40 PM To: Boost Users Mailing List Subject: Suggestion for boost::dll:import_alias<>() or boost::dll::import<>() Hi, I have been experimenting with the Boost.DLL library and I have discovered that the “lib” argument of either boost::dll::import_alias<>() or boost::dll::import<>() functions require the full path to the shared library to load. If I’m not mistaken, this functions use either the POSIX dlopen() function or the Windows LoadLibrary() function. These platform specific functions are capable of searching a list of paths if a non-qualified shared library name is given. My suggestion is to use this search capability for non-qualified shared library names. Kind regards, Leo Carreon

1 0

Suggestion for boost::dll:import_alias<>() or boost::dll::import<>()
by Leo Carreon 19 Jun '16

19 Jun '16

Hi, I have been experimenting with the Boost.DLL library and I have discovered that the “lib” argument of either boost::dll::import_alias<>() or boost::dll::import<>() functions require the full path to the shared library to load. If I’m not mistaken, this functions use either the POSIX dlopen() function or the Windows LoadLibrary() function. These platform specific functions are capable of searching a list of paths if a non-qualified shared library name is given. My suggestion is to use this search capability for non-qualified shared library names. Kind regards, Leo Carreon

1 0

is parallel-bgl active?
by Salvador Aguiñaga 17 Jun '16

17 Jun '16

Installing on a local 2 core system on a cluster ends in errors Installing on small system I want to use for temporary development, I get the following error. > > >parallel-bgl-0.7.0/boost/property_map/property_map.hpp:16:37: fatal > error: boost/pending/cstddef.hpp: No such file or directory > compilation terminated > > I've configured the system: > >"sudo apt-get install build-essential" > > And successfully installed the openmpi: "openmpi-1.10.2.tar.bz2" > > But when I get to: > /parallel-bgl-0.7.0/build/cmake .. > > I can't find a good solution online to this cstddef.hpp error. > > Any suggestions? > > > My system: uname -a > > Linux atomix 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 14:46:51 UTC 2015 > i686 i686 i686 GNU/Linux >

1 0

Re: [Boost-users] boost bind, issue moving from 1.57 to 1.60
by Jason Mancini 17 Jun '16

17 Jun '16

We worked around this failure by changing: Func = boost::bind(Func, _1) && boost::bind(&Boom::Oops, _1); to Func = boost::bind(AND, Func, &Boom::Oops, _1); // custom AND function Not sure why it used to work, or why it still works with raw pointers, but not shared_ptr. The actual change happens from 1.59 (working) to 1.60 (changed behavior). Jason

4 11