Boost C++ Libraries: {5} Assigned, Active Tickets by Owner (Full Description)

#2628: Sequence concept incorrectly fails for basic_string

Thu, 01 Jan 2009 03:38:48 GMT

The Sequence concept fails when tested against basic_string (e.g. BOOST_CONCEPT_ASSERT((Sequence<T>)); ) because an extra constructor test is included. This test is for X a(n) where n is the size of the sequence to be created. However, section 23.1.1 table 67 of the C++ standard does not include this test in the definition of the Sequence concept. Because this test is in place, basic_string is rejected by the current implementation of the Sequence concept, since basic_string does not have this constructor. However, section 21.3 paragraph 2 of the C++ standard states, "The class template basic_string conforms to the requirements of a Sequence, as specified in (23.1.1)."

The fix for this should be as simple as removing the test for a constructor of the form X a(n) in the Sequence concept implementation.

#7729: concept_def.hpp multiple inclusion prevention macro bug

moala@… — Fri, 23 Nov 2012 14:35:43 GMT

In boost/concept/detail/concept_def.hpp, the BOOST_CONCEPT_DETAIL_CONCEPT_DEF_DWA200651_HPP macro does not apply to the whole include file (search for its pending endif).

As a consequence, the following warning appearing e.g. when including boost/graph/adjacency_list.hpp:

"BOOST_concept" redefined
[...]

#9939: Patch to add "no exceptions" support to dynamic_bitset

Tue, 22 Apr 2014 22:09:13 GMT

This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc.

#1215: Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)

hfp@… — Sun, 26 Aug 2007 15:31:24 GMT

#if defined(_MSC_VER) is not the right thing for MinGW because _MSC_VER is defined but the compiler is still from GNUs Compiler Collection. But i am not sure about the MinGW support in general.

Regard, Hans.

#1549: Boost.MPL: 'index_of' algorithm is not documented

Aleksey Gurtovoy — Fri, 04 Jan 2008 02:24:33 GMT

#2041: MPL: more comprehensive test coverage for "fail" situations requiring diagnostics

Aleksey Gurtovoy — Mon, 23 Jun 2008 21:07:19 GMT

See http://thread.gmane.org/gmane.comp.lib.boost.user/36876

#4064: std::bad_cast should be thrown with BOOST_THROW_EXCEPTION

Andreas Huber — Sun, 04 Apr 2010 10:33:25 GMT

Also, other try/catch/throw statements should be put into appropriate #ifndef blocks.

Reported by Thomas Mathys.

#6894: Highlight context forwarding in async state machine docs

Andreas Huber — Sun, 13 May 2012 21:17:44 GMT

(as reported by Sebastian Hoffmann)

#4063: Add debugging support

Andreas Huber — Sun, 04 Apr 2010 09:48:56 GMT

See <http://thread.gmane.org/gmane.comp.lib.boost.user/52305>

#4062: Write a FAQ item on why state constructors do not have access to event data

Andreas Huber — Sun, 04 Apr 2010 09:33:16 GMT

The following techniques should be mentioned:

transition actions & store data in an outer state
repost in transition action & react in an in-state reaction
triggering_event

#9827: Missing support for some code page(e.g 949, 950) in windows conversion with std backend

hucaonju@… — Wed, 02 Apr 2014 09:55:42 GMT

There is a table windows_encoding all_windows_encodings[] in wconv_codepage.ipp. It contains several code page definitions. However, it misses some code pages, such as the Korean code page(949) or Traditional Chinese Big5 code page(950), which will cause an invalid_charset_error when running in that windows for the following code:

// Assuming we are using the std backend so it supports ansi encodings
boost::locale::generator gen;
gen.use_ansi_encoding(true);
std::locale loc(gen(""));
// Throws invalid_charset_error when running in Korean windows but OK in English windows.
// The charset is "windows949" in Korean windows, which is not in the table.
std::string us = boost::locale::conv::to_utf<char>("abcdefg", loc);

The root cause of this exception is that the generated code page string is not in the table. When the locale generator with std backend in windows platform generates a locale, it calls boost::locale::util::get_system_locale(bool use_utf8). This function will use the following code to generate the locale string(in default_locale.cpp):

if(GetLocaleInfoA(LOCALE_USER_DEFAULT,LOCALE_IDEFAULTANSICODEPAGE,buf,sizeof(buf))!=0) {
    if(atoi(buf)==0)
        lc_name+=".UTF-8";
    else {
        lc_name +=".windows-";
        lc_name +=buf;
    }
}

So the encoding part of the lc_name is windows-(code page). In a system with Korean(949) or Traditional Chinese(950) code page, this will generate an encoding string like "windows-949" or "windows-950". However, when wconv_from_utf::open() initializes, it tries to search "windows949" or "windows950" in array all_windows_encodings[]. Obviously it will not find the string, and the open() fails, then the exception is thrown.

For a quick fix, I suggest adding the missing code page to the table:

{ "cp949",      949, 0 }, // Korean
{ "uhc",        949, 0 }, // From "iconv -l"
{ "windows949",         949, 0 }, // Korean
// "big5" already in the table
{ "windows950",         950, 0 }, // TC, big5

However the list may not be complete, and we may encounter problems when running in a system with code page that does not exist in the list. So we may probably add the following code to function int encoding_to_windows_codepage(char const *ccharset) in wconv_codepage.ipp:

--- E:\Build1\boost_1_55_0\libs\locale\src\encoding\wconv_codepage.ipp	2014-04-02 16:34:52.000000000 +0800
+++ E:\Build2\boost_1_55_0\libs\locale\src\encoding\wconv_codepage.ipp	2014-04-02 17:31:37.000000000 +0800
@@ -206,12 +206,18 @@
                 return ptr->codepage;
             }
             else {
                 return -1;
             }
         }
+        if(ptr==end && charset.size()>7 && charset.substr(0,7)=="windows") {
+            int cp = atoi(charset.substr(7).c_str());
+            if(IsValidCodePage(cp)) {
+                return cp;
+            }
+        }
         return -1;
     }
     template<typename CharType>
     bool validate_utf16(CharType const *str,unsigned len)

This piece of code directly parses and validates the encoding string. The concern is that the call to IsValidCodePage may decrease the performance(not tested).

#11848: Win32 backend bug when do wide char convert to multi byte in boost::locale

fyrestone@… — Wed, 16 Dec 2015 05:26:31 GMT

The function wide_to_multibyte_non_zero in locale/src/encoding/wconv_codepage.ipp has bug. This function assume that when the codepage is CP_UTF7 or CP_UTF8, the substitute_ptr and subst_char_ptr will be 0. But, in x64 Windows 10, I use codepage 54936 get 87 error code after the first WideCharToMultiByte called. This will make n is zero, and the second WideCharToMultiByte call will make the program crash.

In MSDN shipped with Visual Studio .NET 2003 it is said that parameters lpDefaultChar and lpUsedDefaultChar must be NULL not only for CP_UTF7 and CP_UTF8, but also for all codepages mentioned in notes for dwFlags parameter:

50220 50221 50222 50225 50227 50229 57002 through 57011 65000 (UTF-7) 42 (Symbol)

It is still true as of Windows 8 & 10: if you try to call

BOOL bVal = FALSE;

WideCharToMultiByte(50220, 0, L"asdf", 4, NULL, 0, NULL, &bVal);

You'll get 0 with GetLastError 87 (ERROR_INVALID_PARAMETER).

#9685: Boost.Locale does not link against static ICU on Windows

stathis@… — Wed, 19 Feb 2014 23:06:28 GMT

There seems to be no support for linking against the static ICU libraries (sicuXX.lib) on Windows. Is there any plans to add it (?), or is there an inherent problem?

I would be willing to write that support if there is a bit of guidance on how to go about it in the Jamfile.

#7266: Gettext path formats.

166291@… — Thu, 23 Aug 2012 05:47:10 GMT

I'm extremely happy about Boost.Locale, but I've found a few things
lacking. So at first I wrote a some wrappers to get around a few flaws
with my usage of Boost.Locale. One of these flaws was how it's hardcoded
to use the Gettext directory hierarchy.
I'd rather store my stuff in 'lang/en_US.mo' rather than
'lang/en_US/LC_MESSAGES/my_app.mo'.
The patch adds a 'path format' feature, which allows you to format the
directory structure when finding Gettext catalogs, to achieve the effect
above. All you really have to do is run:
   gen.add_path_format("{1}/{2}.mo"); // Use a smaller hierarchy.
to achieve the result that I prefer, or
   gen.add_path_format("{1}/{2}/{3}/{4}.mo"); // Use a Gettext hierarchy.
to achieve the result that Boost.Locale uses right now. Ripped straight
from Doxygen comments:
   {1} A path to search for catalogs in.
   {2} The locale's name.
   {3} The locale's category.
   {4} The Gettext domain.

I apologize for the cut and paste from it but I'm having trouble with trac. The full thread with patches can be found at: http://lists.boost.org/Archives/boost/2012/08/195789.php

#3478: Min cut interface for BGL

Tue, 22 Sep 2009 14:00:56 GMT

1) The max flow can be obtained with: (any of the max_flow algorithms, kolmogorov is just used as an example)

double flow = kolmogorov_max_flow(g, SourceNode, SinkNode);

It would be nice to also interpret this max flow as a min cut. I.e. be able to tell which nodes of g belong to the "source side" of the graph and which nodes belong to the "sink side"? Maybe something like a std::vector<unsigned int> GetSourceSideNodes(); return the IDs of the nodes on the source side std::vector<unsigned int> GetSinkSideNodes();return the IDs of the nodes on the sink side std::vector<unsigned int> GetCutEdges(); return the IDs of the edges which were cut

2) Allow the min cut algorithm to accept multiple sources/sinks. The cut should simply be the minimum sum of edges that can be severed to split the graph so that all of the sinks are on one side of the cut and all of the sources are on the other side of the cut.

3) Find the minimum cut that partitions the graph into two parts without specifying a source/sink? I.e. the minimum of all of the possible source/sink pairs minium cuts.

4) Currently you must use a bidirectional graph, and specify an edge_reverse_t in the graph traits, then set the reverse edge for every edge. a) this is pretty complicated for someone who is unfamiliar with generic programming. b) If an undirected graph is used, the algorithm should automatically take care of adding these reverse edges if they are required for the cut to be performed.

5) VERY simple examples (actually constructing a graph (not reading it from file) with < 10 nodes) should be provided to demonstrate all of these cases.

#6063: resize does not offset rectangles (etc.) correctly or crashes

dbfaken@… — Wed, 26 Oct 2011 21:18:46 GMT

When using the 'corner_fill_arc' parameter to polygon_set_concept<T>::resize(), a minkowski sum using a polygonalized circle is used to get the offset shape.

A symptom of the problem is demonstrated by the following code:

 {
  polygon_set_data<int> ps1, ps2, ps3;
  ps1.insert(rectangle_data<int>(0, 0, 50, 50));
  ps2.insert(rectangle_data<int>(0, 0, 50, 50));
  ps3.insert(rectangle_data<int>(0, 0, 50, 50));
  std::cout << "rect before resize: " << ps1 << std::endl;
  ps1.resize(6, true, 0);
  ps2.resize(6, true, 5);
  ps3.resize(6, true, 6);
  rectangle_data<int> ps1_extents, ps2_extents, ps3_extents;
  extents(ps1_extents, ps1);
  extents(ps2_extents, ps2);
  extents(ps3_extents, ps3);
  std::cout << "extents of resized rect with '0' (4) segments in circle: " << ps1_extents << std::endl;
  std::cout << "extents of resized rect with 5 segments in circle: " << ps2_extents << std::endl;
  std::cout << "extents of resized rect with 6 segments in circle: " << ps3_extents << std::endl;
  }

If I put this at the end of the gtl_boost_unit_test.cpp, I get the following output:

rect before resize: Polygon Set Data { <0 0, 50 0>:1 <50 0, 50 50>:-1 <0 50, 50 50>:-1 <0 0, 0 50>:1 }
extents of resized rect with '0' (4) segments in circle: -5 54 -5 54
extents of resized rect with 5 segments in circle: -6 54 -6 55
extents of resized rect with 6 segments in circle: -6 55 -6 56

This shows that the extents of the offset shape vary as the number of segments does - which should not be the case!

The extents should all be: -6 56 -6 56

The problem (to my eyes) is that the polygonalized circle does not generally have the right shape to get proper offsets in axis-oriented directions, so the offset is basically multiplied by some factor of sqrt(2). Attached is an image of the circle generated with num_circle_segments=16. The radius of the circle - i.e. distance from center to each vertex - is 2. The grid spacing is 1. As can be seen, the top/bottom and left/right sides of the circle do not lie on the grid. If the circle started with a vertex at(0,2) this would not occur and one would presumably get proper offsets in axis-aligned directions. Alternately one could offset all the vertices slightly farther, but this would offset some vertices farther than desired.

I would guess the fix is to change the behaviour of make_arc(), which generates these points, but I'm not sure exactly what the original author's intent was - so maybe just using a new function would be best (after all, the complexity of make_arc is overkill when you're generating a simple full circle)

Another problem is that the behaviour of the 'corner_fill_arc' parameter is not really well described. Using this gives much more than corner-filling behaviour - it gives different offsets in different directions. I would suggest explaining it as it is - a minkowski sum with a polygonalized circle, with all that implies.

E.g. for a 45-degree segment the offset will differ from a 90-degree segment unless you pick the right value of num_circle_segments.

Maybe a more comprehensible solution would be to implement corner rounding by the intersection of the normal resize()d shape (as given by corner_fill_arc=false) with the resize()d shape given by corner_fill_arc=true with a larger 'resizing' (picked so that the minimum resizing equals the original resizing).

This would only affect corners, instead of the whole shape.

#7984: In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons

jp.charras@… — Tue, 05 Feb 2013 19:25:06 GMT

I am using boost:: polygon to calculate sum or difference of sets of polygons. Recently, When calcualting the difference of 2 sets of polygons, I found 2 cases creating a serious issue: Depending on the shape of polygons ( a slight change "fix" the bug) I have one case which create no polygon and one (in fact 2 samples) which crashes.

In the sample which calculate the difference between 2 polygon sets, there are 2 polygon sets: one creates no polygon, and the other crashes.

This it reproducible under Linux or Windows-gcc-mingw, with different gcc versions and boost version. (I tried to make the polygons as simple as possible) (see comments inside the sample).

I have used a lot boost:: polygon, and I have only 2 cases which fails (Seems related to a particular shape, not to a polygon complexity)

Thanks to the developpers.

#11315: Compilation warnings created by boost::polygon::operators

lopresti@… — Sun, 17 May 2015 18:36:41 GMT

When I compile bp_warn.cc (attached) with Clang and enable "-Wall -Werror", the compilation fails with "template argument uses unnamed type". See attached "warnings.txt" for complete output.

This took me a little while to track down, since the error occurs on a call to "*" using primitive types (!).

I am not sure this is really a bug in boost::polygon, and I am not sure how to fix it if it is, but I thought I would report it anyway.

#11415: crash in processEvent_

mhilferink@… — Tue, 23 Jun 2015 10:39:41 GMT

In polygon/details/polygon_arbitrary_formation.hpp, at the end of function processEvent_ (line 1768), I had a case where iter is dereferenced illegally.

Changing line 1741 from:

if(verticalTail && !(verticalCount.second)) {

if (verticalTail && !(verticalCount.second) && iter != scanData_.end()) {

fixes this problem, but it might be the case that this just misses the addition of a new hole.

I have processed many polygons and this only happened with a specific polygon, but looking at the iter determining code earlier in processEvent_ (lines 1669..1698), iter referring to the end of scanData might not be such a special case:

iterator iter = lookUp_(currentY);

while(iter != scanData_.end() && ((iter->first.pt.x() == x_ && iter->first.pt.y() == currentY) or (iter->first.other_pt.x() == x_ && iter->first.other_pt.y() == currentY))) {

elementIters.push_back(iter);

...

++iter;

}

If the original coder assumed that (verticalTail && !(verticalCount.second)) implies that (iter != scanData_.end()), well, sometimes it does not. I'll provide more info on actual case(s) (instantiation types, coordinates) in additional notes.

In the seen case, scanData_ contained 3 elements, and elementIters had 2.

#10772: boost::geometry::within() does not recognize empty boxes

bromeon@… — Sat, 08 Nov 2014 19:04:31 GMT

If boost::geometry::within() is used to check whether an empty box (i.e. a point) is within another box, false is always returned. This is not the correct behavior because:

OGC defines: a.Within(b) ⇔ (a∩b=a) ∧ (I(a)∩E(b)=∅) which holds true. The intersection of an empty box a and a surrounding box b yields a. Since a has no interior, I(a)=∅, thus the second condition is also true.
Empty boxes should be treated as points. When using a point model instead of an empty box, the check returns the correct result as expected.

See also the following complete minimal code (it includes also other geometry algorithms that are computed consistently for points and empty boxes):

#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/box.hpp>
#include <boost/geometry/algorithms/convert.hpp>
#include <boost/geometry/algorithms/within.hpp>
#include <boost/geometry/algorithms/covered_by.hpp>
#include <boost/geometry/algorithms/intersects.hpp>
#include <boost/geometry/algorithms/disjoint.hpp>
#include <boost/geometry/algorithms/distance.hpp> // needed for within() -- is this intended?
#include <iostream>
namespace bg = boost::geometry;
typedef bg::model::d2::point_xy<float> Point;
typedef bg::model::box<Point> Box;
int main()
{
    Point point(3, 4);
    Box pointAsBox;
    bg::convert(point, pointAsBox);
    Box surrounding;
    surrounding.min_corner() = Point(2, 2);
    surrounding.max_corner() = Point(5, 5);
    std::cout << "            Point Box" << std::endl;
    std::cout << "within:        " << bg::within(point,      surrounding)
                         << "    " << bg::within(pointAsBox, surrounding)     << "\n"; // 1 0 <-
    std::cout << "within (self): " << bg::within(point,      point)
                         << "    " << bg::within(pointAsBox, pointAsBox)      << "\n"; // 1 0 <-
    std::cout << "covered_by:    " << bg::covered_by(point,      surrounding)
                         << "    " << bg::covered_by(pointAsBox, surrounding) << "\n"; // 1 1
    std::cout << "intersects:    " << bg::intersects(point,      surrounding)
                         << "    " << bg::intersects(pointAsBox, surrounding) << "\n"; // 1 1
    std::cout << "disjoint:      " << bg::disjoint(point,      surrounding)
                         << "    " << bg::disjoint(pointAsBox, surrounding)   << "\n"; // 0 0
    std::cout << std::endl;
}

The implementation looks as follows (boost/geometry/strategies/cartesian/box_in_box.hpp, line 32):

struct box_within_range
{
    template <typename BoxContainedValue, typename BoxContainingValue>
    static inline bool apply(BoxContainedValue const& bed_min
                , BoxContainedValue const& bed_max
                , BoxContainingValue const& bing_min
                , BoxContainingValue const& bing_max)
    {
        return bing_min <= bed_min && bed_max <= bing_max // contained in containing
            && bed_min < bed_max;                         // interiors overlap
    }
};

The problem is the second line, which uses < and thus returns false if the coordinates are equal. I'm not sure what the intention is (despite the comment), and whether it is needed at all.

The documentation about box model and concept doesn't state whether max_corner's coordinates must be component-wise greater or equal than min_corner's. If so, it seems like valid boxes are a precondition to within() and this line could be removed.

#11421: [geometry] rstar segmentation fault boost version 1.58.0

Thu, 25 Jun 2015 20:23:15 GMT

Notes:

The segmentation fault does not occur with boost version 1.55.0.
Discovered when upgrading from Boost 1.55.0 to Boost 1.58.0.
When inserting large numbers (greater than 10⁴) of geometry::model::box objects into an geometry::index::rtree object that uses the boost::geometry::index::rstar algorithm, a segmentation fault occurs.

system information:

gcc (Gentoo 4.8.2 p1.0, pie-0.5.8) 4.8.2

Linux dctest1 3.4.0-gentoo-01 #1 SMP Sun May 27 15:51:01 CDT 2012 x86_64 Intel(R) Xeon(R) CPU X5675 @ 3.07GHz GenuineIntel GNU/Linux

MemTotal: 198094372 kB

test program used to reproduce segmentation fault:

// File: test.cpp
#include <iostream>
#include <boost/geometry.hpp>
#include <boost/geometry/index/rtree.hpp>
// NOTE: 1250, 800 makes 10^6 geo fences
const int NUM_BOXES_LAT = 1250;
const int NUM_BOXES_LON = 800;
const float MAX_LAT_DEG = 61.2167f; // Anchorage AK
const float MIN_LAT_DEG = 25.7877f; // Miami FL
const float MAX_LON_DEG = -68.7703f; // Bangor ME
const float MIN_LON_DEG = -149.9000f; // Anchorage AK
const float DELTA_LAT_DEG = (MAX_LAT_DEG - MIN_LAT_DEG)/static_cast<float>(NUM_BOXES_LAT);
const float DELTA_LON_DEG = (MAX_LON_DEG - MIN_LON_DEG)/static_cast<float>(NUM_BOXES_LON);
using COORD_TYPE = boost::geometry::cs::cartesian;
using Point = boost::geometry::model::point<float, 2, COORD_TYPE>;
using Box = boost::geometry::model::box<Point>;
using BoxIDPair = std::pair<Box, unsigned>;
int main()
{
  // Create a grid of boxes evenly distributed across North America.
  // Test Note: swap out rtree algorithms to isolate seg fault problem
//  boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::rstar<16, 4> > locationGeometryTable; // seg fault @ 10^4 boxes
  boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::rstar<16> > locationGeometryTable; // seg fault @ 10^4 boxes
//  boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::quadratic<16> > locationGeometryTable; // pass @ 10^4 boxes; pass @ 10^6
  for(unsigned idxLat=0; idxLat<NUM_BOXES_LAT; ++idxLat)
  {
    float lat = idxLat*DELTA_LAT_DEG + MIN_LAT_DEG;
    for(unsigned idxLon=0; idxLon<NUM_BOXES_LON; ++idxLon)
    {
      float lon = idxLon*DELTA_LON_DEG + MIN_LON_DEG;
      unsigned boxID = idxLat*idxLon;
      // Directly map to cartesian: lon is X; lat is Y
      Point pt0(lon, lat);
      Point pt1(lon+0.001f, lat+0.001f);
      Box box(pt0, pt1);
      locationGeometryTable.insert(std::make_pair(box, boxID));
    }
  }
  return 0;
}

build:

$ gcc -std=c++11 -lstdc++ -I$BOOST_ROOT/include -DBUFFERSIZE=4096 -g -O0 test.cpp -o test

run:

$ ./test
Segmentation fault

debug:

$ gdb ./test
GNU gdb (Gentoo 7.5 p1) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from test...done.
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: test
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7651127 in __memmove_ssse3_back () from /lib64/libc.so.6
(gdb) backtrace
#0  0x00007ffff7651127 in __memmove_ssse3_back () from /lib64/libc.so.6
#1  0x00000000004165fa in boost::geometry::index::detail::varray_detail::copy_dispatch<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (first=0x7fffffffc188, last=0x7fffffffc1b8,
    dst=0x406a6a <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::---Type <return> to continue, or q <return> to quit---
index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+62>)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray_detail.hpp:201
#2  0x0000000000413ee6 in boost::geometry::index::detail::varray_detail::copy<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (
    first=0x7fffffffc188, last=0x7fffffffc1b8,
    dst=0x406a6a <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost---Type <return> to continue, or q <return> to quit---
::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+62>)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray_detail.hpp:224
#3  0x0000000000411a03 in boost::geometry::index::detail::varray<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_interna---Type <return> to continue, or q <return> to quit---
l_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, 17ul>::assign_dispatch<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (
    this=0x406a62 <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allo---Type <return> to continue, or q <return> to quit---
cator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+54>, first=0x7fffffffc188, last=0x7fffffffc1b8)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray.hpp:1774
#4  0x00000000004100b4 in boost::geometry::index::detail::varray<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, 17ul>::assign<boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (
    this=0x406a62 <boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boos---Type <return> to continue, or q <return> to quit---
t::detail::variant::void_>::apply_visitor<boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+54>, first=0x7fffffffc188, last=0x7fffffffc1b8)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray.hpp:950
#5  0x000000000040e698 in boost::geometry::index::detail::rtree::redistribute_elements<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::rstar_tag>::apply<boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag> > (n=...,
    second_node=..., box1=..., box2=..., parameters=..., translator=..., allocators=...)
---Type <return> to continue, or q <return> to quit---
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/rtree/rstar/redistribute_elements.hpp:442
#6  0x0000000000000003 in ?? ()
#7  0x00007fffffffca00 in ?? ()
#8  0x000000000040b798 in boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::variant<boost::geometry::index::detail::rtree::variant_leaf<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::detail::rtree::options<boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator<boost::geometry::index::indexable<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, boost::geometry::index::equal_to<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> > >, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::allocators<std::allocator<std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int> >, std::pair<boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box<boost::geometry::model::point<float, 2ul, boost::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag> >::operator() (
    this=<error reading variable: Cannot access memory at address 0x18>, n=<error reading variable: Cannot access memory at address 0x10>)
    at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/rtree/rstar/insert.hpp:279
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

#5638: greg_month::get_month_map_ptr is not thread safe

Fri, 24 Jun 2011 08:06:03 GMT

We recently have found a crash issue related to this function in greg_month.cpp.

the block from line 39 is not thread safe. If multiple threads call this function simultaneously, it will lead to a crash. As one thread is populating the map while the other thread may start using the map, or even worse two threads populate the map at the same time.

#605: Support different DST rules in timezone db based on years

nobody — Mon, 17 Apr 2006 13:20:56 GMT

The boost time library supports processing of the
timezone database file as a .csv, with one entry per
time zone, such as "America/New_York".  However, in
2007, the daylight savings time rules will change.  The
contents of the csv need to change, to incorporate a
range of effective years.  Since DST is a spring and
fall event (in both north and south hemispheres) only a
year need be recorded.
I suggest adding two values at the beginning of the
line, (as one field in the form nnnn-nnnn) for the low
effective-year and high effective-year, as 4-digit
values.  Let 0000 be used for "all previous years" and
9999 be used for all subsequent years.  [If the '-'
separator is a problem, ':' could be used instead.]
Then, the change in 2007 can be recorded as two lines:
"2007-9999","America/New_York", ...
"0000-2006","America/New_York", ...
Lines unaffected by the change would have "0000-9999"
as the first field.

#889: Insane Dependencies

nobody — Mon, 09 Apr 2007 23:07:09 GMT

From: helvey@accelrys.com
Simply including boost/date_time/posix_time headers causes build times to skyrocket. Building a file that includes boost/date_time/posix_time/posix_time.hpp takes almost a minute, removing the header drops the time to less than a second.
Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :)

#1207: Method "from_julian_day_number" (class gregorian_calendar) not documented

thom_schu@… — Thu, 23 Aug 2007 10:19:03 GMT

please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ? library: date_time

thanks

gizmo

#3132: Provide conversions to time_t

Andrey Semashev — Thu, 04 Jun 2009 09:23:12 GMT

Extracted from #889.

==========8<============ Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :) ==========>8============

Need to provide conversion function from Boost.DateTime types to std::time_t.

#8183: boost::geometry::intersection on two polygons returns incorrect empty intersection

matthewd@… — Tue, 26 Feb 2013 09:24:56 GMT

The code snippet intersects 2 2D polygons resulting in an empty intersection. I'm including an image of the two polygons and they are overlapping. There may be a problem because the polygons share an overlapping edge?

Thanks

Matthew Danielsen

polygon_2d triangle2D;
{
    const double triangle2Dcoor[] = {{0.891747, 2.28756}, {0.490911, -1.52549}, {-1.72945, -1.52549}, {0.891747, 2.28756}};
    assign(triangle2D, triangle2Dcoor);
}
polygon_2d box2D;
{
    const double box2Dcoor[] = {{-1.6744, -1.52549}, {-1.70498, -1.52549}, {-1.70052, -1.49155}, {-1.67049, -1.49579}, {-1.6744, -1.52549}};
    assign(box2D, box2Dcoor);
}
boost::geometry::model::multi_polygon< boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<T> > > intersectionPolygons;
boost::geometry::intersection(triangle2D, box2D, intersectionPolygons);
assert(intersectionPolygons.size() != 0); //  Assert fails

#8366: "Overlay invalid input exception" (3)

Tue, 02 Apr 2013 08:19:24 GMT

Please find below some code that triggers "Overlay invalid input exception" (in the last statement of the example). I have a couple of different reproductions, and since I'm not sure if they all share the same root cause, I'm filing them in separate tickets.

As always, my polygon type is oriented counter-clockwise and not closed, my point type is based on int.

This is the data that triggers the exception:

_intPolygon polygon( "MULTIPOLYGON(((529 998,5337 998,5337 3475,529 3475)))" );
{
       _intPolygon const polygonB = _intPolygon("MULTIPOLYGON(((528 3314,1734 2054,2934 1670,4140 1754,5340 2072,5340 32767,528 32767)))") ^ _intPolygon("MULTIPOLYGON(((528 3218,1734 1784,2934 1400,4140 2582,5340 1832,5340 32767,528 32767)))");
       polygon -= polygonB;
}
{
       _intPolygon const polygonB = _intPolygon("MULTIPOLYGON(((528 3218,1734 1784,2934 1400,4140 2582,5340 1832,5340 32767,528 32767)))") ^ _intPolygon("MULTIPOLYGON(((528 2498,1734 1406,2934 1574,4140 3002,5340 1178,5340 32767,528 32767)))");
       polygon -= polygonB;
}
{
       _intPolygon const polygonB = _intPolygon("MULTIPOLYGON(((528 2498,1734 1406,2934 1574,4140 3002,5340 1178,5340 32767,528 32767)))") ^ _intPolygon("MULTIPOLYGON(((528 2420,1734 2186,2934 2378,4140 2750,5340 1250,5340 32767,528 32767)))");
       polygon -= polygonB;
}
{
       _intPolygon const polygonB = _intPolygon("MULTIPOLYGON(((528 2420,1734 2186,2934 2378,4140 2750,5340 1250,5340 32767,528 32767)))") ^ _intPolygon("MULTIPOLYGON(((528 1724,1734 2552,2934 1640,4140 2396,5340 1460,5340 32767,528 32767)))");
       polygon -= polygonB;
}

This is my code that wraps boost::geometry to implement the operators used above:

template<typename T>
template<typename Geometry>
_TPolygon< T > _TPolygon< T >::operator-(Geometry const& geometry) const
{
       // should not be necessary
       //if( boost::geometry::area(geometry)==0 ) return *this;
       _TPolygon< T > polygonOut;
       boost::geometry::difference(*this, geometry, polygonOut);
       // should not be necessary
       //boost::geometry::correct( polygonOut );
       return polygonOut;
}
template<typename T>
template<typename Geometry>
_TPolygon<T>& _TPolygon< T >::operator-=(Geometry const& geometry)
{
       // boost::geometry::difference cannot operate in-place
       // http://lists.boost.org/geometry/2012/02/1796.php
       *this = *this - geometry;
       return *this;
}
template<typename T>
template<typename Geometry>
_TPolygon< T > _TPolygon< T >::operator^(Geometry const& geometry) const
{
       _TPolygon< T > polygonOut;
       boost::geometry::sym_difference(*this, geometry, polygonOut);
       // should not be necessary
       //boost::geometry::correct( polygonOut );
       return polygonOut;
}

#8701: wrong empty polygon-linestring intersection with overlapping edges

aar@… — Sun, 16 Jun 2013 09:21:11 GMT

The returned intersection between these geometries is empty, although they overlap completely and I would expect the full linestring to be returned:

POLYGON((137372 104999998,137372 97499999,67175839 97499999,67175839 104999998)) LINESTRING(399872 104971332,399872 97528663,2899872 97528663,2899872 104971332,5399872 104971332,5399872 97528663,7899872 97528663,7899872 104971332,10399872 104971332,10399872 97528663,12899872 97528663,12899872 104971332,15399872 104971332,15399872 97528663,17899872 97528663,17899872 104971332,20399872 104971332,20399872 97528663,22899872 97528663,22899872 104971332,25399872 104971332,25399872 97528663,27899872 97528663,27899872 104971332,30399872 104971332,30399872 97528663,32899872 97528663,32899872 104971332,35399872 104971332,35399872 97528663,37899872 97528663,37899872 104971332,40399872 104971332,40399872 97528663,42899872 97528663,42899872 104971332,45399872 104971332,45399872 97528663,47899872 97528663,47899872 104971332,50399872 104971332,50399872 97528663,52899872 97528663,52899872 104971332,55399872 104971332,55399872 97528663,57899872 97528663,57899872 104971332,60399872 104971332,60399872 97528663,62899872 97528663,62899872 104971332,65399872 104971332,65399872 97528663,67175839 97528663)

If I move one of them slightly, I get a correct intersection instead of an empty set. I'm using double for point coordinates.

This issue might be related to #8310 and #8183.

#11580: invalid buffer result

Tue, 25 Aug 2015 10:00:19 GMT

The following code example produces invalid results. Reducing the distance e.g. from 2.37 to 1 produces correct results. I have tested this code with boost 1.57 and boost 1.59 with the same results.

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/geometries.hpp>
namespace bg = boost::geometry;
int main()
{
	typedef bg::model::point<double, 2, bg::cs::cartesian> point;
	typedef bg::model::polygon<point> polygon;
	polygon poly;
	bg::read_wkt("POLYGON((14.02 474.96,14.02 494.96,14.022 494.96,14.022 486.24,14.02 474.96))", poly);
        bg::strategy::buffer::distance_symmetric<double> distance_strategy(2.37);
	bg::strategy::buffer::side_straight side_strategy;
	bg::strategy::buffer::join_miter join_strategy;
	bg::strategy::buffer::end_flat end_strategy;
	bg::strategy::buffer::point_circle point_strategy;
	bg::model::multi_polygon<Polygon> grown;
	bg::buffer(poly, grown, distance_strategy, side_strategy, join_strategy,
			   end_strategy, point_strategy);
	std::cout << bg::wkt(grown) << std::endl;
	return 0;
}

The returned shape is:

MULTIPOLYGON(((16.39 474.96,16.3842 474.795,16.3669 474.63,16.3382 474.467,16.2982 474.307,16.2471 474.149,16.1851 473.996,16.1126 473.847,16.0299 473.704,15.9374 473.567,15.8355 473.437,15.7248 473.314,15.6058 473.199,15.4791 473.092,15.3453 472.995,15.205 472.908,15.0589 472.83,14.9078 472.763,14.7524 472.706,14.5934 472.66,14.4315 472.626,14.2677 472.603,14.1027 472.591,13.9373 472.591,13.7723 472.603,13.6085 472.626,13.4466 472.66,13.2876 472.706,13.1322 472.763,12.9811 472.83,12.835 472.908,12.6947 472.995,12.5609 473.092,12.4342 473.199,12.3152 473.314,12.2045 473.437,12.1026 473.567,12.0101 473.704,11.9274 473.847,11.8549 473.996,11.7929 474.149,11.7418 474.307,11.7018 474.467,11.6731 474.63,11.6558 474.795,11.65 474.96,11.6558 475.125,11.6731 475.29,11.7018 475.453,11.7418 475.613,11.7929 475.771,11.8549 475.924,11.9274 476.073,12.0101 476.216,12.1026 476.353,12.2045 476.483,12.3152 476.606,12.4342 476.721,12.5609 476.828,12.6947 476.925,12.835 477.012,12.9811 477.09,13.1322 477.157,13.2876 477.214,13.4466 477.26,13.6085 477.294,13.7723 477.317,13.9373 477.329,14.1027 477.329,14.2677 477.317,14.4315 477.294,14.5934 477.26,14.7524 477.214,14.9078 477.157,15.0589 477.09,15.205 477.012,15.3453 476.925,15.4791 476.828,15.6058 476.721,15.7248 476.606,15.8355 476.483,15.9374 476.353,16.0299 476.216,16.1126 476.073,16.1851 475.924,16.2471 475.771,16.2982 475.613,16.3382 475.453,16.3669 475.29,16.3842 475.125,16.39 474.96)))

#12125: Another problems performing boolean operations on polygons with shared edges

ev.mipt@… — Wed, 13 Apr 2016 22:43:43 GMT

Trying to solve problems with union_ operation on mpolygons with shared edges (https://svn.boost.org/trac/boost/ticket/12118) with help of boost 1.61.0 beta. But instead of getting problems with zero areas, I'm getting really wrong result.

For example

currentPath
MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438)))

appended Polygon
MULTIPOLYGON(((7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,13.00057315826416015625 -33.85240554809570312500,7.83307075500488281250 -32.98977279663085937500)),((-22.50806808471679687500 -27.92480468750000000000,7.83307075500488281250 -32.98977279663085937500,-14.87041568756103515625 -6.99879980087280273438,-22.50806808471679687500 -27.92480468750000000000)))

Union result (same as currentPath, appended Polygon was totally ignored)
MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438)))

#13072: boost::geometry::intersection different results for CCW and CW

kle@… — Wed, 14 Jun 2017 10:57:24 GMT

Hello,

when calculating the intersection between these two polygons the results differ dependent on the orientation (CW vs CCW).

#include <boost/geometry/geometry.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
int main(int argc, char* argv[])
{
  typedef boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double>, true,  false >  boost_polygon_CW_Open;
  typedef boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double>, false, false > boost_polygon_CCW_Open;
  const std::string strPoly1( "POLYGON((986.53314901320903 603.61376367962623, 1014.6804499149767 602.74037774442763, 1018.1411735073581 623.97665453539310, 990.14493850604447 624.49725628790509))" );
  const std::string strPoly2( "POLYGON((986.77183669558929 603.60635741124452, 998.79457181965154 603.23330253835934, 1002.2613711877982 623.79581100129735, 990.30090761267468 624.02156931285253))" );
  boost_polygon_CW_Open p1_cw_open, p2_cw_open;
  boost::geometry::read_wkt(strPoly1, p1_cw_open);
  boost::geometry::read_wkt(strPoly2, p2_cw_open);
  boost::geometry::correct(p1_cw_open); // reverts order of points
  boost::geometry::correct(p2_cw_open); // reverts order of points
  std::vector<boost_polygon_CW_Open> output_cw;
  boost::geometry::intersection(p1_cw_open, p2_cw_open, output_cw); // correct: output_cw.front equals poly2
  boost_polygon_CCW_Open p1_ccw_open, p2_ccw_open;
  boost::geometry::read_wkt(strPoly1, p1_ccw_open);
  boost::geometry::read_wkt(strPoly2, p2_ccw_open);
  boost::geometry::correct(p1_ccw_open); // no modification
  boost::geometry::correct(p2_ccw_open); // no modification
  std::vector<boost_polygon_CCW_Open> output_ccw;
  boost::geometry::intersection(p1_ccw_open, p2_ccw_open, output_ccw); // incorrect: output_cw is empty!!!
  return 0;
}

#13444: boost::geometry::buffer returns only partial result (regression over 1.63.0)

andre.meyer@… — Fri, 09 Feb 2018 10:44:56 GMT

using boost::geometry::buffer with multilinestring, only 1 of expected 3 polygons are returned.

The fix ist to buffer each linestring separately and union_ them into one multipolygon. This also turned out to be much faster.

I do not have a simple example, but a rather complex one, which I will attach.

Version 1.63.0 returned all 3 polygons, but was also rather slow when compared with the workaround.

#13522: Invalid empty result using boost::geometry::difference

lehnert@… — Mon, 16 Apr 2018 09:43:01 GMT

Hello,

executing the following polygon difference operation sequence produces an obviously incorrect empty result. The first difference produces a (possibliy) valid result with a spike which might be the actual problem. The third difference with the previous result generates an empty result. The intermediate difference is required the reproduce this behaviour. Without it the result of the third difference is correct. Removing the spike from step one also solves the problem.

Code to reproduce this:

using point_type = boost::geometry::model::d2::point_xy<double>; using polygon = boost::geometry::model::polygon<point_type>; using multi_polygon = boost::geometry::model::multi_polygon<polygon>;

BoostGeometryBridge::Polygon2d_t Right[3]; BoostGeometryBridge::MultiPolygon2d_t Left[4];

boost::geometry::read_wkt("MULTIPOLYGON(((0.747399249902131135 -0.974867609298678328,0.744720465461241043 -0.984866128861542012,0.737400169703072983 -0.992186849248596014,0.72740024741975795 -0.994866631198703,0.169444950081761997 -0.994882813404528998,0.156263880981993009 -0.992649068186161054,0.144555091741144004 -0.986196591543298973,0.135626528763234999 -0.976246166252738967,0.0970341390445131069 -0.91515608670535098,0.0527935015388215009 -0.831873652851741974,0.0149278636239085008 -0.745505885364162957,-0.016349202846282801 -0.656539920475841976,-0.0408612872409169006 -0.56547754891590496,-0.0584701351532070993 -0.472832385681689005,-0.0690764281904878985 -0.379126973119241983,-0.0726203441553292944 -0.284889833651171986,-0.0690818944579700972 -0.19065248877542601,-0.058481036857029399 -0.0969464611485150035,-0.0408775628926898033 -0.00430027666216776031,-0.0163707606471800993 0.086763516577464006,0.0149011452653820004 0.17573129555438699,0.0527617733210207981 0.262101259307556012,0.0969975799226773933 0.345386259216249991,0.135586426022915013 0.406478577227274984,0.144514411807557003 0.416429520405822984,0.156222826750318011 0.422882676210660002,0.169403766258661992 0.42511718599825099,0.727359063596658029 0.425133368204076989,0.737359141304932963 0.422454166307816015,0.744679861691986966 0.415133870549649009,0.747359067455327319 0.405136098375181386,0.747329770868999987 1.43513394783313997,2.74732976755064007 1.43524915817017007,2.74708725756255978 5.64524915118547987,-2.74750006237453981 1.25999999251885009,-2.74749997944197011 -4.43500000748115042,0.747500020558034994 -4.43500000604748035,0.747399249902131135 -0.974867609298678328),(-2.49638915854706989 0.152811596222504009,-1.75719536363572004 1.80498971421238008,-1.01782283569549992 1.4741902811305001,-1.75234596398119002 -0.167548384003570999,-1.76762179055725999 -0.173243028570225999,-2.49638915854706989 0.152811596222504009)))", Left[0]);

boost::geometry::read_wkt("POLYGON((-1.57590744074229994 2.19505211912179998,-2.74750006237453981 1.25999999251885009,-2.74750004134586989 -0.184043917378418992,-1.76796680349592994 -0.184043903114115004,-1.74492840055212994 -0.175455463366190001,-1.00461083616106994 1.47923439340570995,-1.57590744074229994 2.19505211912179998))", Right[0]); boost::geometry::read_wkt("POLYGON((2.74708725756255001 5.64524915118547987, 1.48149582377297007 4.63517624723808019, 2.7471454369183701 4.6352491528611397, 2.74708725756255001 5.64524915118547987))", Right[1]); boost::geometry::read_wkt("POLYGON((-2.74749997944197011 -4.43500000748115042, -2.74750006237453981 1.25999999251885009, -3.11250006493298015 1.43568817247817004, -3.11249997689355018 -4.61000000763086959, -2.74749997944197011 -4.43500000748115042))", Right[2]);

for(int i = 0; i < 3; i++) {

boost::geometry::difference(Left[i], Right[i], Left[i + 1]);

}

Final result in Left[3] is empty.

#13553: intersection gives wrong result

marnix.berg@… — Mon, 30 Apr 2018 14:04:02 GMT

The following polygons result in a wrong intersection:

using point_type = boost::geometry::model::d2::point_xy<double>; typedef boost::geometry::model::ring<point_type, false, true> polygon;

polygon op1, op2;

boost::geometry::read_wkt("POLYGON((7.7058932076134967 -11.523889618379748,8.0348094747518424 0.63492733448631888,7.7720440433489850 0.63492733448631888, 7.7058932076134967 -11.523889618379748))", op1); boost::geometry::read_wkt("POLYGON((2.6206910206017642 -32.773696844382265, 5.5835888947200090 -24.273798818378602, 6.7109368565951772 -20.023839227004206, 7.4191426214038723 -15.773870150408516, 7.7058941612236938 -11.523876267001913, -3.1025600674348395 -11.523582486001384, -3.1025610210450365 -32.773541282571529, 2.6206910206017642 -32.773696844382265))", op2); std::vector<polygon> result; boost::geometry::intersection(op1, op2, result);

result is equal to op1, while op1 is mostly outside op2.

#5734: possible handle leak in posix implementation copy_file_api

alexey.kutumov@… — Tue, 26 Jul 2011 04:04:07 GMT

There is possible handle leak in POSIX implementation of function copy_file_api.

...
    if ((infile = ::open(from_p.c_str(), O_RDONLY))< 0)
      { return false; }
    struct stat from_stat;
    if (::stat(from_p.c_str(), &from_stat)!= 0)
      { return false; }
...

if ::stat failed, then function exits without closing infile handle.

This problem exists both in v3 and v2 implementations of filesystem. Also this problem exists in previous releases.

#5850: last_write_time on Windows may not work on SMB2-network-mounted drive

Wed, 31 Aug 2011 15:22:13 GMT

Consider the following logical operation against a file on a network-mounted drive served over SMB2:

fopen("r+b")/fwrite/fclose a file.
boost::filesystem::last_write_time(file, some other specific time)
fopen("rb")/fclose a file.

As soon as the file is opened in step 3, it appears that the SMB2/redirector actually closes the file and "flushes" its pending write in service of step 1. This has the effect of overwriting the time modification in step 2.

I believe this is happening because boost's non-POSIX/Windows implementation of last_write_time uses CreateFile() and asks only for FILE_WRITE_ATTRIBUTES. Using GENERIC_WRITE appears to work correctly.

Also note, calling utime() instead of boost::filesystem::last_write_time() works correctly.

Please see attached test code demonstrating boost's failure, utime()'s success, and native API workaround.

Please feel free to contact me for follow up. Thanks, -Ken

#5937: Sun C++ 5.11 Linux compilation errors: operations.cpp

Sat, 24 Sep 2011 12:46:46 GMT

CC: Sun C++ 5.11 Linux_i386 2010/08/13 usage: CC [ options ] files. Use 'CC -flags' for details

"libs/filesystem/v3/src/operations.cpp", line 1760: Error: DT_UNKNOWN is not defined.

"libs/filesystem/v3/src/operations.cpp", line 1766: Error: DT_DIR is not defined.

"libs/filesystem/v3/src/operations.cpp", line 1768: Error: DT_REG is not defined.

"libs/filesystem/v3/src/operations.cpp", line 1770: Error: DT_LNK is not defined.

4 Error(s) detected.

"CC" -library=stlport4 -xO4 -mt -erroff=%none -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"." -c -o "/home/pal/work/cpp/tmp/boost/bin.v2/libs/filesystem/build/sun/release/address-model-64/link-static/stdlib-sun-stlport/threading-multi/v3/src/operations.o" "libs/filesystem/v3/src/operations.cpp"

#6188: boost directory_iterator construct throw segmentation fault

anonymous — Thu, 01 Dec 2011 04:13:41 GMT

Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory.

#6638: convert_aux fails while intializing global variable

Wed, 29 Feb 2012 22:39:27 GMT

path_traits.cpp

convert_aux fails in global scope:

Trying to initialize global path variable by concatenating '/' a wide string path w/ narrow string path fails!

"Unhandled exception at 0x0f8bc688 (msvcp100d.dll) in paths.exe: 0xC0000005: Access violation reading location 0x00000000."

If initializing inside main() scope everything works fine. I think this worked as expected in previous version(s) 1.48.. no luck with 1.49 though :(

Additional info: WIN 32 and 64 bit, MSVS2010

#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
path p(L"C:\\TEMP\\");
path q(p / L"wide");  // Works!
path r(p / "narrow"); // Breaks :(
int _tmain(int argc, _TCHAR* argv[])
{
    path p(L"C:\\TEMP\\");
    path q(p / L"wide");  // Works!
    path r(p / "narrow"); // Works here!
    std::cout << r.string() << std::endl;
	return 0;
}

P.S. If more info is required I will reply here not by email.

#8388: windows_file_codecvt should be allocated with _NEW_CRT

pedro.larroy@… — Thu, 04 Apr 2013 10:08:14 GMT

Due to a bug in VC libraries, when allocating windows_file_codecvt it should be done with _NEW_CRT instead of new. Otherwise if operator new is overriden in the userland application it would be a crash since windows_file_codecvt is allocated with the user provided operator new and deallocated with delete from the C runtime.

#8642: Global locale prevents from using Boost.Filesystem in global constructors and destructors

Andrey Semashev — Mon, 03 Jun 2013 13:06:50 GMT

The problem appears in particular with Boost.Log. On program termination, Boost.Log may attempt to perform final log file rotation, which involves calling Boost.Filesystem routines (path construction, in particular). But Boost.Filesystem is not usable at this point because its global locale is already destroyed.

Boost.Filesystem should remain usable during global constructors and destructors. The global locale should either be embedded into the path object (preferred solution, IMHO) or the library should ensure its availability during these stages.

#9816: boost::filesystem::is_empty does not work for symbolic links on Windows

Sun, 30 Mar 2014 10:11:13 GMT

Hi,

I'm using boost::filesystem::is_empty() to check if configuration files I'm using are empty. Due to our software deployment these files are mostly symbolic links created with the Windows 7 internal mklink command.

I've used Boost 1.46.1 in the past for this and everything worked fine. Lastly I upgraded to 1.55.0 and found out that is_empty does not work anymore.

I at first asked at Stackoverflow for some help: Boost::filesystem::is_empty() returns false for Symlinks

I also created a Github project which reproduces the problem: Github - BoostSymLinkError

#9824: boost::filesystem::is_empty() doesn't work with symlinks on Windows

michael.burr@… — Tue, 01 Apr 2014 09:17:13 GMT

See the original information on this problem in this Stackoverflow question:

hxxp://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks

The person who reported that problem/asked the question on Stackoverflow also set up a github project that demonstrates the problem:

hxxps://github.com/monsdar/BoostSymLinkError

Basically, the filesystem::is_empty() function doesn't follow a symlink, so it will return false even if the target of the symlink has a length greater than 0.

The V2 filesystem library worked for this situation. The difference is that V2 used the stat() function in the VC++ library, while the V3 filesystem library uses the Win32 GetFileAttributesExW() API. The latter does not follow symlinks and returns a file size of 0 regardless of the size of the symlink target.

Attached is a diff for libs/filesystem/src/operations.cpp which uses the stat() technique very similar to what was used in filesystem V2. A few differences:

_wstat() is used instead of stat() to accommodate UNICODE filenames
a bit test using _S_IFDIR is used to determine if the path is a directory instead of S_ISDIR() because the VC++ library doesn't include a S_ISDIR() or _S_ISDIR() macro.

This patch is only lightly tested (MSVC++ 12.0, 32-bit, on Win7 x64, filenames with ASCII characters only). I'm not sure what the motivations for changing to the GetFileAttributesExW() API in filesystem V3 were, so I'm not sure if there's a fundamental flaw in using _wstat() that would prevent using it in V3.

#10205: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid

sleary@… — Wed, 16 Jul 2014 11:59:58 GMT

Ok this is still broken (see Ticket #5928). On Solaris 10 (sparc) compile this...

#include <iostream> #include <boost/filesystem.hpp>

int main (void) {

std::cout << boost::filesystem::unique_path("/some/random/path/%%%%%%%").c_str() << std::endl; return 0;

}

linking against system and filesystem

I had compiled boost_1_55_0 from the site and built just filesystem and system (because program_options fails to compile with gcc 4.9.0 but thats a separate issue). I created the above example in stage/lib folder and ran..

g++ test.cpp -I../../ -L. -lboost_filesystem -lboost_system

Below are the results...

bash-3.2$ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.ISO8859-1 LC_NUMERIC=en_GB.ISO8859-1 LC_TIME=en_GB.ISO8859-1 LC_COLLATE=en_GB.ISO8859-1 LC_MONETARY=en_GB.ISO8859-1 LC_MESSAGES=C LC_ALL= -bash-3.2$ LC_ALL=en_GB.UTF-8 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

Abort (core dumped) -bash-3.2$ LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

Abort (core dumped) -bash-3.2$ LC_ALL=en_GB.ISO8859-1 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

Abort (core dumped) -bash-3.2$ LC_ALL=C LD_LIBRARY_PATH=. ./a.out /some/random/path/7fff459

This is utterly crippling and renders boost filesystem useless on Solaris 10.

#10233: create_directories causes invalid read

Wed, 23 Jul 2014 13:48:27 GMT

The following code, when run under Valgrind, will report two instances of invalid reads during program close (after main).

Tested on Ubuntu Linux x64 12.04 (kernel 3.8.0) with gcc 4.6.3.

#include <stdlib.h>
#include <boost/filesystem.hpp>
int main()
{
	system("rm -rf /tmp/test"); // make sure directory doesn't already exist
	boost::filesystem::create_directories("/tmp/test");
	return 0;
}

#10485: heap-use-after-free using C++11 range loop

iamvfx@… — Tue, 09 Sep 2014 16:14:17 GMT

Repro code:

#include <stdio.h>
#include <boost/filesystem.hpp>
int main() {
    boost::filesystem::path dir("/");
    for (char c : dir.filename().string())
        printf("%c\n", c);
}

I know if I want to fix it I should store dir.filename().string() in a variable (and it works), but in this case it will either crash application or print garbage. Here's what Clang Address Sanitizer prints:

=================================================================
==12324==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000ef50 at pc 0x48448a bp 0x7fff08f73990 sp 0x7fff08f73988
READ of size 8 at 0x60300000ef50 thread T0
    #0 0x484489 in std::string::size() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716
    #1 0x484489 in ~path /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:636
    #2 0x484489 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6
    #3 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64)
    #4 0x483f1c in _start (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x483f1c)
0x60300000ef50 is located 0 bytes inside of 26-byte region [0x60300000ef50,0x60300000ef6a)
freed by thread T0 here:
    #0 0x46e7b9 in operator delete(void*) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e7b9)
    #1 0x4843f2 in std::string::_M_rep() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:249
    #2 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539
    #3 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539
    #4 0x4843f2 in ~path /usr/include/boost/filesystem/path.hpp:55
    #5 0x4843f2 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6
    #6 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64)
previously allocated by thread T0 here:
    #0 0x46e4b9 in operator new(unsigned long) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e4b9)
    #1 0x7f067a3411d8 (/lib64/libstdc++.so.6+0xbe1d8)
    #2 0x9
SUMMARY: AddressSanitizer: heap-use-after-free /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716 std::string::size() const
Shadow bytes around the buggy address:
  0x0c067fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c067fff9de0: fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd fa fa
  0x0c067fff9df0: 00 00 00 02 fa fa 00 00 00 03 fa fa 00 00 00 02
  0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c067fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap right redzone:    fb
  Freed heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==12324==ABORTING

#10900: read_symlink fails to correctly read NTFS junctions

Fri, 26 Dec 2014 16:16:26 GMT

Tested on Windows 7 64-bit.

NTFS directory junctions are now recognized as a symlink by is_reparse_point_a_symlink but read_symlink does not correctly handle those "mount point" reparse points yet.

Among other things this also breaks the canonical operation.

The REPARSE_DATA_BUFFER returned by DeviceIoControl needs to be accessed differently for regular symlinks and mount points. See msdn.microsoft.com/en-us/library/ff552012.aspx

Accessing the "PrintName" as a symlink typically results in the first two (wide) characters of the path being skipped and generally in undefined behavior.

A possible fix would be to add a conditional statement checking info.rdb.ReparseTag == IO_REPARSE_TAG_MOUNT_POINT and then amend the symlink_path.assign call accordingly (using info.rdb.MountPointReparseBuffer instead of info.rdb.SymbolicLinkReparseBuffer).

In version 1.57.0 the offending code can be found in libs/filesystem/src/operations.cpp around line 1514.

#2150: Inspect needs to check for missing files

Beman Dawes — Mon, 28 Jul 2008 14:51:59 GMT

Objective: Report missing files early enough to take corrective action before a crisis develops. Include generated doc files in the lists searched for.

Design: Top level "required_files.txt" points to "required_files.txt" in subdirectories. That way the root/required_files.txt only has to be edited when a library is added.

See attached file for possible "required_files.txt" format.

#3965: missing functions last_access_time() and last_status_change_time()

Sascha Ochsenknecht — Sun, 28 Feb 2010 05:35:24 GMT

In Boost.Filesystem I can find a function:

template <class Path> std::time_t last_write_time(const Path& p);

which is corresponding to st_mtime (last modification time) of the stat structure. Within the stat structure, their are also st_atime and st_ctime defined, but there are no corresponding functions. Is there a special reason for that? Couldn't they be added?

template <class Path> std::time_t last_access_time(const Path& p); template <class Path> std::time_t last_status_change_time(const Path& p);

Cheers, Sascha

#4494: recursive_directory_iterator throws unexpectedly in the non-throw mode

ttan@… — Fri, 30 Jul 2010 06:13:15 GMT

In boost::filesystem v3, while it’s possible to choose a no-throw version of recursive_directory_iterator by passing an boost::system::error_code object to its constructor, like this:

boost::system::error_code m_ec; for ( recursive_directory_iterator itr(root, m_ec), end_itr; itr != end_itr; ++itr)

However, because in the implementation of the recursive_directory_iterator::increment(), directory_iterator is always constructed with the throw version, it would cause exception throws during the for-loop while accessing folders like \System Volume Information on Windows:

void increment() {

BOOST_ASSERT(m_imp.get() && "increment of end recursive_directory_iterator"); m_imp->increment(0); if (m_imp->m_stack.empty()) m_imp.reset(); done, so make end iterator

}

Where m_imp is an object of recur_dir_itr_imp:

void recur_dir_itr_imp::increment(system::error_code* ec) ec == 0 means throw on error

{ … }

As it’s not possible to catch this exception within the for-loop and continue the loop, it greatly limits the use of recursive_directory_iterator. With a rough check, V2 does not seem to have this problem. it's preferred that the directory_iterator to behave the same as recursive_directory_iterator in this case.

#5896: Range directory iterators

jmckesson@… — Tue, 13 Sep 2011 22:42:39 GMT

With C++11 now finalized as a standard, and compilers being more compliant every day, it makes sense to have range-based versions of the directory_iterator classes. This would make it much easier to use the range-based for loop, as well as Boost.Range functionality.

Basically, it could just be a couple of helper functions that create a boost::iterator_range<bfs::directory_iterator> instance.

#6018: Add touch() and create_file() functions

Beman Dawes — Thu, 13 Oct 2011 12:38:26 GMT

A function with the functionality of the POSIX touch utility would be a great convenience. It meets both the need to update times and the need to create a file.

OTOH, it is a bit of a mishmash of logically separate features. Maybe what is really needed is a create_file() function that errors if the file already exists and a touch() function that errors if the file doesn't exist.

Alternatively, both could return a bool, true if successful, and not consider it an error if the file, respectfully, already/doesn't exist.

#6521: Directory listing using C++11 range-based for loops

mustrumr97@… — Sat, 04 Feb 2012 18:15:21 GMT

I have written a simple 'container' class for a directory, 'containing' all of its subdirectories:

namespace boost{
    namespace filesystem{
        class directory{
            path p_;
            public:
                inline directory(path p):p_(p){
                    return;
                }
                directory_iterator begin(){
                    return directory_iterator(p_);
                }
                directory_iterator end(){
                    return directory_iterator();
                }
        };
    }
}

so that that range-based for loop can be used:

for(auto i:directory("/home")){
    ...
}

#10078: Incomplete API with respect to file related dates (cration, modification, access)

Thu, 29 May 2014 09:38:36 GMT

The following features are missing:

read file's creation date
read file's last access date
read file's creation date with a precision higher than seconds
read file's last access date with a precision higher than seconds
read file's last access date with a precision higher than seconds
allow to detect capabilities of the underlying filesystem (e.g. support for creation and last access date that are not supported by all systems, or finding out date precision supported by the current filesystem)

Possible implementation notes:

How to get high precision file date on Linux

http://stackoverflow.com/questions/13382695/how-to-get-last-modification-time-of-a-file-with-epoch-time-format-precision-mi

How to get high precision file date on Windows

http://msdn.microsoft.com/en-us/library/aa364946.aspx

Example of current use of this feature in existing applications:

ls --full-time

#11663: No way to query file extension without allocating memory

matthew.chaplain@… — Thu, 17 Sep 2015 06:44:37 GMT

the function .extension() returns an fs::path, containing a fresh string that contains the extension. On certain library implementations that don't implement the SSO -- or, I guess, for files with very long extensions -- there will be a memory allocation each time the function is called.

That means that for solutions implementing search-by-extension such as is written in:

http://stackoverflow.com/questions/11140483/how-to-get-list-of-files-with-a-specific-extension-in-a-given-folder

there could be hundreds of memory allocations for just iterating a directory structure. IMO, there really shouldn't be.

I propose adding the function bool path::has_extension(string const&) which can compare the extension in a memory-friendly way.

#2066: Inspect needs to review generated doc files too

Beman Dawes — Thu, 03 Jul 2008 11:16:35 GMT

Inspect needs to run on release snapshot so that it is looking at the generated doc files too.

But it also needs to be modified so that if it is running on a snapshot (or other cases where svn info doesn't work), the revision number and URL are picked up from somewhere else.

Maybe it would be easier to copy the files from the release snapshot into a release working copy so that inspect will work as it is not.

#5745: Use native typeof support for Oracle Solaris Studio C++ compiler

Mon, 01 Aug 2011 14:51:58 GMT

Oracle Solaris Studio (former SunStudio) C++ compiler supports native typeof since version 5.9. At the same time, support for typeof emulation is not so good (many compilation errors). It would be beneficial for Boost users if Boost used native typeof instead of emulation.

Here is proposed patch:

*** boost/typeof/typeof.hpp	2011-08-01 18:46:33.411406362 +0400
--- boost/typeof/typeof.hpp.new	2011-08-01 18:46:43.680746049 +0400
***************
*** 155,160 ****
--- 155,176 ----
  #   else
  #       error native typeof is not supported
  #   endif
+ #elif defined(__SUNPRO_CC)
+ #   if (__SUNPRO_CC < 0x590 )
+ #	ifdef BOOST_TYPEOF_NATIVE
+ #	    error native typeof is not supported
+ #	endif
+ #	ifndef BOOST_TYPEOF_EMULATION
+ #	    define BOOST_TYPEOF_EMULATION
+ #	endif
+ #   else
+ #	ifndef BOOST_TYPEOF_EMULATION
+ #	    ifndef BOOST_TYPEOF_NATIVE
+ #		define BOOST_TYPEOF_NATIVE
+ #	    endif
+ #	    define BOOST_TYPEOF_KEYWORD __typeof__
+ #	endif
+ #   endif
  #else //unknown compiler
  #   ifndef BOOST_TYPEOF_NATIVE
  #       ifndef BOOST_TYPEOF_EMULATION

#2875: Windows: ip::tcp::acceptor::local_endpoint() cannot be used in socket connect

Fri, 20 Mar 2009 06:19:50 GMT

On linux the local_endpoint() function returns an endpoint similar to 0.0.0.0:1234. A socket which is given this endpoint to connect to will connect successfully. A similar endpoint is returned on Windows, however the socket connection is not successful.

I am currently working around this problem by inserting loopback as the address to connect to. For the sake of consistency between platforms it may be worthwhile including a similar substitution within the socket's connect operation if 0.0.0.0 is detected.

#9991: WConversion issue in json_parser_write.hpp

abhi.california@… — Fri, 02 May 2014 06:21:11 GMT

File Name: 1_54_0/boost/property_tree/detail/json_parser_write.hpp

There is a severe problem with the -Wconversion issue in the json_parser_write.hpp

Problematic code:

else

{

const char *hexdigits = "0123456789ABCDEF"; typedef typename make_unsigned<Ch>::type UCh; unsigned long u = (std::min)(static_cast<unsigned long>(

static_cast<UCh>(*b)),

0xFFFFul);

int d1 = u / 4096; u -= d1 * 4096;

int d2 = u / 256; u -= d2 * 256; int d3 = u / 16; u -= d3 * 16; int d4 = u;

result += Ch('
'); result += Ch('u'); result += Ch(hexdigits[d1]); result += Ch(hexdigits[d2]); result += Ch(hexdigits[d3]); result += Ch(hexdigits[d4]);

}

Either we need to do explicit static cast to suppress the Conversion Warning. When we turn on the -Wconversion as well as -Werror both together, which is good practice for production ready code. compiler Just dont allow this to compile.

the above need to be fixed.

#10188: Loses floating point precision on round trip

Thu, 10 Jul 2014 13:54:12 GMT

ptrees stream_translator uses a precision of std::numeric_limits<F>::digits10 + 1 when converting floating point values. This is not always enough, and a more correct value would be digits10+2 or max_digits10 (c++11 only). See ticket:9177 for a similar issue.

The attached test produces the following output pre-patch:

in : -1.8312345000098765e-08
out: -1.8312345000098762e-08
Wrong

and after patch:

in : -1.8312345000098765e-08
out: -1.8312345000098765e-08
Right

#11502: narrow_encoding: -Wtype-limits warning is reported

davido — Sun, 26 Jul 2015 12:28:26 GMT

-Wtype-limit is reported on this assert:

char to_internal_trivial(char c) const {

assert(c <= 0x7f); <=== Type limit return c;

}

#5658: how to get rid of nasty compiler warning in boost/property_tree/detail/rapidxml.hpp

Wed, 29 Jun 2011 07:39:25 GMT

compiling e.g libs/graph/src/graphml.cpp warns ...

/boost/property_tree/detail/rapidxml.hpp: In function `size_t boost::property_t
ree::detail::rapidxml::internal::get_index(Ch) [with Ch = char]':
./boost/property_tree/detail/rapidxml.hpp:1413:   instantiated from `static unsi
gned char boost::property_tree::detail::rapidxml::xml_document<Ch>::whitespace_p
red::test(Ch) [with Ch = char]'
./boost/property_tree/detail/rapidxml.hpp:1542:   instantiated from `static void
 boost::property_tree::detail::rapidxml::xml_document<Ch>::skip(Ch*&) [with Stop
Pred = boost::property_tree::detail::rapidxml::xml_document<char>::whitespace_pr
ed, int Flags = 3072, Ch = char]'
./boost/property_tree/detail/rapidxml.hpp:1377:   instantiated from `void boost:
:property_tree::detail::rapidxml::xml_document<Ch>::parse(Ch*) [with int Flags =
 3072, Ch = char]'
./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:116:   instantiated fr
om `void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream<
typename Ptree::key_type::value_type, std::char_traits<typename Ptree::key_type:
:value_type> >&, Ptree&, int, const std::string&) [with Ptree = boost::property_
tree::basic_ptree<std::string, std::string, std::less<std::string> >]'
./boost/property_tree/xml_parser.hpp:52:   instantiated from `void boost::proper
ty_tree::xml_parser::read_xml(std::basic_istream<typename Ptree::key_type::value
_type, std::char_traits<typename Ptree::key_type::value_type> >&, Ptree&, int) [
with Ptree = boost::property_tree::ptree]'
libs/graph/src/graphml.cpp:49:   instantiated from here
./boost/property_tree/detail/rapidxml.hpp:317: warning: comparison is always fal
se due to limited range of data type

Caused by the template:

template<class Ch>
        inline size_t get_index(const Ch c)
        {
            // If not ASCII char, its sematic is same as plain 'z'
            if (c > 255)
            {
                return 'z';
            }
            return c;
        }

How to avoid ? Just specify additionally a user defined implementation of get_index for the "char" type :

        inline size_t get_index(const char c)
        {
            return c;
        }
        template<class Ch>
        inline size_t get_index(const Ch c)
        {
            // If not ASCII char, its sematic is same as plain 'z'
            if (c > 255)
            {
                return 'z';
            }
            return c;
        }

I checked the code size (using gcc4.0) : same and the difference of the ASM code: "same"

14972c14972
<       cmpq    (%r15), %rdi
---
>       cmpq    %rdi, (%r15)
14974c14974
<       jae     .L3637
---
>       jbe     .L3637
15002c15002
<       cmpq    -16(%rsi), %rdi
---
>       cmpq    %rdi, -16(%rsi)
15004c15004
<       jae     .L3643
---
>       jbe     .L3643
15017c15017
<       cmpq    -16(%rdx), %rdi
---
>       cmpq    %rdi, -16(%rdx)
15019c15019
<       jb      .L3796
---
>       ja      .L3796
15487c15487
---

#8565: Lists in admonitions

thomas.moeck@… — Mon, 13 May 2013 11:12:38 GMT

It seems not to be possible to include lists in admonitions.

E.g. the following won't work, meaning no list will be displayed but just the stars as characters:

[note Some text for my note

first point I want to note
second point I want to note

]

#1558: Optional separate compilation

Daniel James — Sun, 06 Jan 2008 18:41:53 GMT

There are some parts of Boost.Unordered that could be compiled into a library file. Provide an option to do this.

#1979: More example hash functions

Daniel James — Sun, 01 Jun 2008 10:17:27 GMT

#2448: syntax highlighting for code in documentation or website

hagai26@… — Wed, 29 Oct 2008 19:56:48 GMT

In Boost documentation there are a lot of code examples which it would be better if it will be with syntax highlighting to be more readable.

#8545: Can quickbook support parts and chapters as well as sections?

John Maddock — Fri, 03 May 2013 15:56:14 GMT

Currently the only "top level" structure supported is the section, but it would be very useful for longer documents have to have support for chapters, parts and appendixes as well. As far as I know these can't be implemented as templates as these get <para>...</para> wrapped around them even when they're block templates.

#1175: Document quickbook's (lack of) unicode support.

Joel de Guzman — Mon, 13 Aug 2007 11:23:21 GMT

See http://tinyurl.com/35j57v

#1279: Make sure multiple #import of a file imports the file only once.

Joel de Guzman — Mon, 24 Sep 2007 06:37:48 GMT

#1487: Update the writing documentation instructions

Daniel James — Fri, 30 Nov 2007 20:01:35 GMT

The documentation (http://www.boost.org/more/writingdoc/structure.html) needs to updated and probably should be moved to the new site.

#4442: Simple implementation of operator * for matrices with 0 complexity

Thu, 15 Jul 2010 22:47:25 GMT

The following is a simple implementation of operator * for matrix-matrix and matrix-vector which simply forwards to the existing prod() implementation.

Since nested products A * B * C can't work yet, it does a compile time check to make sure this isn't occuring.

See attached patch and test file. Note that this also has patched changes for ticket #4441 built in

#3936: [xpressive] stack overflow.

shewitt.au@… — Tue, 16 Feb 2010 14:56:20 GMT

The following simple program fires a stack overflow exception in xpressive. It's seems too simple to be causing such problems.

{{{#include "stdafx.h" #include <string> #include <boost/xpressive/xpressive.hpp> using namespace boost::xpressive;

int _tmain(int argc, _TCHAR* argv[]) {

sregex rx = ~(set='{', '}', ','); sregex rx2 = +rx;

std::string s(10000, 'a'); regex_search(s, rx2);

return 0;

}}}}

I'm using MSVC 2005. The problem only occurs if the string is large.

#6992: accumulator's median feature skips 1st two data points.

polyactis@… — Sat, 16 Jun 2012 01:10:15 GMT

Hi,

I used accumulator's median feature to calculate mean/median of input data. I also used armadillo library's mean/median. The mean from two libraries always agree. However the medians don't. I tried to give 1,2,3,4,5 input data to the program. and found accumulator's median outputs 0 if the number of input data is 1 or 2. It starts to output non-zero median if given more than 2 data points however, first two data points are not used.

Please check what is going on.

Thanks, yu

#3519: It should be possible to use consts as external placeholder variables.

ami.ganguli@… — Mon, 12 Oct 2009 15:26:05 GMT

The right-and-side of placeholder let-expressions are not declared as const, so common use-cases like:

placeholder<int> _i;
smatch what;
what.let(_i = 1);

or:

placeholder<MyClass *> _p;
smatch what;
what.let(_p = this);

fail to compile. It would be nice to have some way to specify a placeholder for non-mutable data. Perhaps:

placeholder<int const> _i;

(suggested by Eric Niebler)

#4704: Support for multicapture and balancing groups

erik@… — Sun, 03 Oct 2010 09:05:25 GMT

Feature request ticked to jog Eric Nieblers memory to take a look at some code.

I've added support for multicapture and balancing groups to Boost::Xpressive.

Syntax for pop capture:

dynamic: (?P<-name>stuff)
static: (name -= stuff)

Syntax for capture conditional:

dynamic: (?P(name)stuff)
static: (name &= stuff)

The changes are in the vault and can be found here: http://tinyurl.com/3aak7mp

It can be unpacked against trunk from 2010-10-02 or the 1.44.0 release. I've run the dynamic regression tests without errors and I have added some tests for the new functionality. The code it only tested on Visual Studio 2010 since I don't have access to any other compiler.

Erik Rydgren

#6891: Add extension point to define how expressions are created from operators

Mathias Gaunard — Sat, 12 May 2012 16:15:55 GMT

As discussed here: <http://lists.boost.org/proto/2012/05/0637.php>

It would be nice to add a mechanism to allow to define what the operator overloads created by Proto will do. Unlike other functions where a Proto-based library can construct nodes the way it wishes, there is no control and what the built-in C++ operators do.

#4668: Conditions for operator overload in Proto (documentation)

Tue, 21 Sep 2010 20:00:16 GMT

Taken from this thread in boost-users: http://lists.boost.org/boost-users/2010/09/62747.php

This explanation by Thomas Heller would make a good section for the proto documentation:

In order for a proto overload to be created the following conditions must be
true:
1) the operands must be in a compatible domain
2) the left hand operand and the right hand operand must match the grammar
specified in the domain
3) the resulting expression must match the grammar specified in the domain.

To illustrate what this means, this minimalistic example might be useful, too:

This grammar

proto::plus<proto::terminal<int>, proto::terminal<int> >

used in a domain would not allow

i + i;

with i being an int-terminal.

#12880: Alignment information @ PP time

Domagoj Šarić — Wed, 01 Mar 2017 14:42:25 GMT

Please add a macro that can be used for selective compilation based on the guaranteed alignment of the default allocator, i.e. something like: https://bitbucket.org/eigen/eigen/src/d4e10456d28275c27f417efc119024749c979b7e/Eigen/src/Core/util/Memory.h

#2692: No concepts supporting the idea of dense

dougrm@… — Wed, 28 Jan 2009 20:51:45 GMT

data() returns a reference to a Storage. However, nowhere in the concepts is a statement saying that &m.data()[0] must to be the address of the first element of the linearly stored data in the Storage. The adjective "dense" is used all over, but nowhere is this term given any operational guarantees. Without such guarantees, all the interfaces in, say, the numerics::binding libraries are being built on sand. Related to this is that nothing requires unbounded_array<T>::value_type to be T. The problem boils down to the ublas concepts documentation borrowing from the stl vector concepts which are general enough to support vector<bool>. The basic (and inadequate) change is the sprinkling around of the word dense and the phrase "strict linear order". Instead you need to explicitly says things like value_type is T and &v[i+j] == &v[i]+j (for reasonable i+j).

#3396: add a sparse_view class that wraps pre-allocated data into a matrix expression

Gunter — Thu, 03 Sep 2009 20:16:06 GMT

Provide a way to use ublas with pre-allocated data. Implement a matrix view of a CRS matrix as proof of concept. Details:

given 3 arrays: row pointers, column indices, values (http://www.netlib.org/utk/papers/templates/node90.html)

provide a wrapper that fulfills the immutable part of the matrix expression

Further tasks:

split the current matrix and vector concepts into immutable and mutable parts in order to gain a "read-only view" concept and a full featured "expression" concept

improve traits mechanism and apply it where possible to automatically see a fixed size C-array as vector view or matrix view

add necessary tests

#4033: optimized matrix products

Gunter — Mon, 22 Mar 2010 21:38:27 GMT

proposal from Jörn Ungermann:

Abstract

The (lacking) performance of sparse-matrix products was quite often noted on this list. Currently there are several functions which implement matrix products. Each is efficient under certain conditions only and some of them are not even documented. I think it important for users to have one (near-)optimal function only. The attached file contains an improved axpy_prod that matches the performance of "prod", "axpy_prod" and "sparse_prod" and is thereby optimal for all matrix types.

Details

The optimal choice of kernel for a matrix product depends on the properties of all involved matrices. The current implementations specialize only on the type of target matrix. By also determining the kernel depending on the source matrices, one can choose the most efficient kernel. My aim was to create a single function to match the performance of prod, axpy_prod and sparse_prod for all combinations of compressed_matrix/matrix and column/row-majority. The other matrix types should also be handled efficiently by my product, too, but I did check it only spuriously, as it should be obvious that those types are more suited for matrix setup, not for actual calculation. My axpy_prod implementation (called axpy_prod2 in the attached file) does not offer support for the undocumented triangular_expression stuff contained in the original axpy_prod, which however seems to be buggy in the current code for dense matrices. The kernels are largely based on existing kernels with one or two new ones being thrown in. They are as abstract as possible to handle arbitrary expressions efficiently. Specializing, e.g. directly on compressed_matrix would give another very significant performance boost, but also many more additional kernels, possibly more than could be maintained, especially as the transposedness might have to be handled explicitly, too.

It would be very nice, if someone could rewrite prod/prec_prod to handle matrix products in the same way as my axpy_prod2 does, but I did not look deep enough into the expression-templates to do this myself or to even know if this were possible.

In fact, I'd propose to have two sets of interfaces:

1) One convenient one, possibly compromising efficiency
2) One modeled closely after C-BLAS, delivering utmost efficiency.

The latter one could then be *very easily* overloaded by the numeric bindings for dense matrices. I added a possible generic implementation for a gemm call that could be trivially overloaded for dense matrices and forwarded to, e.g., ATLAS numeric bindings.

If one could achieve the same efficiency and automatic (i.e. by including a header) coupling to numeric bindings using only *one* interface, I'd prefer that naturally. However currently, we have not just two, but too many product functions (prod, prec_prod, axpy_prod, sparse_prod, opb_prod, block_prod).

The following table gives the result for all 64 combinations of compressed_matrix/matrix and row/column-majorities for the three involved in this case 2000x2000 matrices.

com_rm is a compressed_matrix of row_major type.
den_cm is a matrix of column_major type.
The 4th column indicates the used kernel.
The 5th column gives the runtime for axpy_prod2 ( clock()/1000 )
The 6th column gives the runtime for sparse_prod ( clock()/1000 )
The 7th column gives the runtime for axpy_prod ( clock()/1000 )
The 8th column gives the runtime for prod ( clock()/1000 )
The 10th column gives the speedup of axpy_prod2 compared to sparse_prod.
The 11th column gives the speedup of axpy_prod2 compared to axpy_prod.
The 12th column gives the speedup of axpy_prod2 compared to prod.

Larger matrix sizes result in prohibitive runtimes for the "slow" products, but can be used to analyse pure-sparse products.

The runtime shall be taken only qualitatively.

One can see that the only cases where the new implementation is slower are of relatively small runtime, so it may be negligible. sparse_prod uses an optimization that is very efficient if the target matrix has few off-diagonal elements, but is very inefficient if it does. The results will therefore vary depending on the test matrices.

It is also obvious to see, why some people complain about product performance, as especially axpy_prod and prod are sometimes ridiculously slow for sparse matrices and sparse_prod does not seem to be documented in the special products section. My favorite case is "com_cm, com_cm, den_rm" one, which actually occurred in the diagnostics part of our application and was the reason why we started looking into this topic.

#1915: Nested matrix products with transposes causes compiler to complain error: invalid application of ‘sizeof’

Wed, 14 May 2008 05:52:05 GMT

When using ublas, a pair of nested products will cause the compiler to complain if there is a trans on any of the operands. For example:

using namespace boost::numeric::ublas;
matrix<float> A(3,3),   B(3,3), C(3,3);
prod(prod(A,B),trans(C));  // fails
prod(prod(trans(A),B),C);  // fails
prod(prod(A,trans(B)),C);  // fails
prod(prod(A,B),C);  // OK

The compiler produces the following error message:

/opt/local/include/boost/numeric/ublas/matrix_expression.hpp: In function ‘typename boost::numeric::ublas::matrix_matrix_binary_traits<typename E1::value_type, E1, typename E2::value_type, E2>::result_type boost::numeric::ublas::prod(const boost::numeric::ublas::matrix_expression<E>&, const boost::numeric::ublas::matrix_expression<E2>&) [with E1 = boost::numeric::ublas::matrix_matrix_binary<boost::numeric::ublas::matrix<float, boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, boost::numeric::ublas::unbounded_array<float, std::allocator<float> > >, boost::numeric::ublas::matrix<float, boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, boost::numeric::ublas::unbounded_array<float, std::allocator<float> > >, boost::numeric::ublas::matrix_matrix_prod<float, float, float> >, E2 = boost::numeric::ublas::matrix_unary2<boost::numeric::ublas::matrix<float, boost::numeric::ublas::basic_row_major<size_t, ptrdiff_t>, boost::numeric::ublas::unbounded_array<float, std::allocator<float> > >, boost::numeric::ublas::scalar_identity<float> >]’:
bad_multiply.cpp:9:   instantiated from here
/opt/local/include/boost/numeric/ublas/matrix_expression.hpp:4815: error: invalid application of ‘sizeof’ to incomplete type ‘boost::STATIC_ASSERTION_FAILURE<false>’

#6545: boost:::python doesn't recognize std::shared_ptr

Sat, 11 Feb 2012 14:03:12 GMT

boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr

#3077: Reverse iterator compile-time bug in multi_array

Mon, 25 May 2009 10:47:28 GMT

I'm having some trouble iterating over a 2-dimensional multi_array in reverse order. I'm using boost 1.38 with gcc-4.2.4 and the following code won't compile with the error given below:

#include <boost/multi_array.hpp>
template< typename It >
void
iterate_over( It begin, It end )
{
    while( end != begin ) {
        begin->end() - begin->begin();
        ++begin;
    }
}
void
test()
{
    boost::multi_array< double, 2 > m;
    iterate_over( m.begin(), m.end() );   // works fine
    iterate_over( m.rbegin(), m.rend() ); // causes error
}

This looks to me like a bug in the implementation of the reverse iterator for multi_array. Am I wrong? It is only a problem when iterator::operator-> is used. The (*begin). notation works fine.

/home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp: In static member function ‘static typename boost::mpl::if_<boost::is_reference<Reference>, Pointer, boost::detail::operator_arrow_proxy<ValueType> >::type boost::detail::operator_arrow_result<ValueType, Reference, Pointer>::make(Reference) [with ValueType = boost::multi_array<double, 1ul, std::allocator<double> >, Reference = boost::detail::multi_array::sub_array<double, 1ul>, Pointer = boost::multi_array<double, 1ul, std::allocator<double> >*]’: /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:648: instantiated from ‘typename boost::detail::operator_arrow_result<typename boost::detail::iterator_facade_types<Value, CategoryOrTraversal, Reference, Difference>::value_type, Reference, typename boost::detail::iterator_facade_types<Value, CategoryOrTraversal, Reference, Difference>::pointer>::type boost::iterator_facade<I, V, TC, R, D>::operator->() const [with Derived = boost::reverse_iterator<boost::detail::multi_array::array_iterator<double, double*, mpl_::size_t<2ul>, boost::detail::multi_array::sub_array<double, 1ul> > >, Value = boost::multi_array<double, 1ul, std::allocator<double> >, CategoryOrTraversal = boost::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::random_access_traversal_tag>, Reference = boost::detail::multi_array::sub_array<double, 1ul>, Difference = long int]’ src/sandbox/seqan_sandbox.cpp:12: instantiated from ‘void iterate_over(It, It) [with It = boost::reverse_iterator<boost::detail::multi_array::array_iterator<double, double*, mpl_::size_t<2ul>, boost::detail::multi_array::sub_array<double, 1ul> > >]’ src/sandbox/seqan_sandbox.cpp:22: instantiated from here /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:326: error: no matching function for call to ‘implicit_cast(boost::detail::multi_array::sub_array<double, 1ul>*)’

#5636: BGL isomorphism vertex invariant interface change

Thu, 23 Jun 2011 22:48:35 GMT

(This is the last isomorphism ticket I think. :-))

I have one more suggestion about how to handle vertex invariants. To determine whether u and v should be considered equivalent by the isomorphism, instead of providing two functors f and g, calling f(u) and g(v) to get a pair of integers, and finally comparing the result, I think it would be cleaner to have a "binary" predicate p which would be called as p(u,v). (In reality of course you'd probably want to have it receive g1 and g2 as well, so it'd really be a 4-arg function.) This should also let you get rid of the vertex_max_invariant parameter perhaps.

I'm not sure of how this would impact the performance or how you'd do sorting, but you could probably do it by doing an N^{2 traversal and recording for each u in g1 how many vs in g2 are considered equivalent. This is a bit different from what you're doing now, I think.}

(The benefit of this would be it becomes easier to impose extra conditions on the isomorphism. Instead of figuring out how to encode everything into an integer -- and worrying about the fact that you make an array of size vertex_max_invariant, so you can't even use all that much of that size -- you can just test it directly.)

#6893: Inaccurate Radians/Degrees conversion

pieterb@… — Sun, 13 May 2012 10:19:17 GMT

LS,

The conversion from angles in degrees to radians currently uses a conversion factor of 6.28318530718/360. (File: boost\units\base_units\angle\degree.hpp), which equals 0.0174532925199444444...

This is unnecessarily inaccurate (only 14 significant digits are correct) and gives problems in my application - the actual value reads: 0.017453292519943295769236907684886127134428718885417...

Using this value improves conversion accuracy significantly.

Please consider using this more accurate value. Alternatively, the use of boost::math::constants could be considered, making the factor: boost::math::constants::pi<double>()/180.0 which works fine as well.

#2801: gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long)

pelee@… — Wed, 25 Feb 2009 20:54:04 GMT

boost::date_time::gregorian_calendar_base() returns an int, but uses several local variables of type unsigned long, leading to warnings about possible loss of data when converting from unsigned long to int on 64 bit OSes that use the LP64 data model.

Here is a rewrite of the function that generates no warnings when compiled with -Wshorten-64-to-32 under GCC 4.0.1 on Mac OS 10.5:

  template<typename ymd_type_, typename date_int_type_>
  BOOST_DATE_TIME_INLINE
  int
  gregorian_calendar_base<ymd_type_,date_int_type_>::week_number(const ymd_type& ymd) {
    date_int_type_ julianbegin = julian_day_number(ymd_type(ymd.year,1,1));
    date_int_type_ juliantoday = julian_day_number(ymd);
    date_int_type_ day = (julianbegin + 3) % 7;
    date_int_type_ week = (juliantoday + day - julianbegin + 4)/7;
    if ((week >= 1) && (week <= 52)) {
      return static_cast<int>(week);
    }
    if ((week == 53)) {
      if((day==6) ||(day == 5 && is_leap_year(ymd.year))) {
        return static_cast<int>(week); //under these circumstances week == 53.
      } else {
        return 1; //monday - wednesday is in week 1 of next year
      }
    }
    //if the week is not in current year recalculate using the previous year as the beginning year
    else if (week == 0) {
      julianbegin = julian_day_number(ymd_type(static_cast<unsigned short>(ymd.year-1),1,1));
      juliantoday = julian_day_number(ymd);
      day = (julianbegin + 3) % 7;
      week = (juliantoday + day - julianbegin + 4)/7;
      return static_cast<int>(week);
    }
    return static_cast<int>(week);  //not reachable -- well except if day == 5 and is_leap_year != true
  }

#10285: local_time is not monotonic

Fri, 01 Aug 2014 08:03:44 GMT

The following snippet seems to generate non monotonic local_date.

I'm using boost 1.55 on linux.

#include <boost/date_time/local_time/local_time.hpp> #include <boost/ptr_container/ptr_vector.hpp>

int main() {

const boost::local_time::time_zone_ptr theTimeZone(

new boost::local_time::posix_time_zone(

"CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00")

);

boost::local_time::local_date_time myOldValue(

boost::local_time::local_microsec_clock::local_time(theTimeZone));

for (size_t i = 0; ; ++i) {

const boost::local_time::local_date_time myLocalTime =

boost::local_time::local_microsec_clock::local_time(theTimeZone);

if (myLocalTime < myOldValue) {

std::cout << myOldValue << std::endl; std::cout << myLocalTime << std::endl; std::cout << boost::local_time::local_microsec_clock::local_time(theTimeZone) << std::endl; std::cout << "====================" << std::endl;

}

myOldValue = myLocalTime;

}

}

As you can see the program is not supposed to print anything ever, however this is what I'm getting:

2014-Jul-31 00:24:56.005625 CEST 2014-Jul-31 00:24:55.005631 CEST <== 1 second back 2014-Jul-31 00:24:56.005946 CEST ==================== 2014-Jul-31 00:24:58.005625 CEST 2014-Jul-31 00:24:57.005629 CEST <== 1 second back 2014-Jul-31 00:24:58.005824 CEST ==================== 2014-Jul-31 00:25:02.005624 CEST 2014-Jul-31 00:25:01.005628 CEST <== 1 second back 2014-Jul-31 00:25:02.005838 CEST ==================== 2014-Jul-31 00:25:04.005625 CEST 2014-Jul-31 00:25:03.005630 CEST <== 1 second back 2014-Jul-31 00:25:04.005826 CEST ==================== 2014-Jul-31 00:25:06.005624 CEST 2014-Jul-31 00:25:05.005633 CEST <== 1 second back 2014-Jul-31 00:25:06.005853 CEST ==================== 2014-Jul-31 00:25:07.005625 CEST 2014-Jul-31 00:25:06.005631 CEST <== 1 second back 2014-Jul-31 00:25:07.005846 CEST ==================== 2014-Jul-31 00:25:12.005625 CEST 2014-Jul-31 00:25:11.005631 CEST <== 1 second back 2014-Jul-31 00:25:12.005822 CEST ====================

as you can see when the local_date is near 0.005631 second fraction it goes back of one second and then forward again on the following call.

#11067: boost::gregorian::date_iterator missing postfix operators ++ and --

dkochin@… — Tue, 03 Mar 2015 16:29:10 GMT

/* Consider the following (somewhat canonical) code snippet */ {

std::vector<boost::gregorian::date> dates(count); auto dt_i = dates.begin(); boost::gregorian::month_iterator m_i(some_start_date, 1);

while (dt_i != dts.end())

*dt_i++ = *m_i++; /* this will call prefix ++ operator on m_i

leading to subtle bug */

}

#10103: setprecision(0) does displays too many digits of a float128

Sat, 07 Jun 2014 12:38:29 GMT

setprecision(0) is not honored for float128. Compare the display of a double and a float128 (default and fixed):

0.1 0.123400000000000000000000000000000006
0 0.123400000000000000000000000000000006

This is produced with

#include <iostream>
#include <boost/multiprecision/float128.hpp>
int main() {
  double x = 0.1234;
  boost::multiprecision::float128 y = 0.1234Q;
  std::cout << std::setprecision(0) << x << " " << y << "\n";
  std::cout << std::fixed << x << " " << y << "\n";
}

#3408: gamma distribution's quantile performance

chhenning@… — Sun, 06 Sep 2009 18:50:32 GMT

Hi there, I have created a test which times the performance of boost::math::quantile( ... ) when using a gamma distribution. I ran it against source code we use here at work, for ages. It can be found here:

http://people.sc.fsu.edu/~burkardt/cpp_src/dcdflib/dcdflib.html

The old source code is about 2x times faster than the boost version.

MS Visual Studio 2005: boost: 35.4sec att_bell:19sec

Intel 11.1: boost: 21.4sec att_bell: 11.2sec

Question is if there is a way to incorporate such a function into boost::math? As far, as I can tell the results are almost identical.

Here the code:

#include <dcdflib.h>

#include <boost/math/distributions/gamma.hpp>

#include <boost/timer.hpp>

double min_mean = 2000; 2,000 double max_mean = 500000000; 500,000,000

double min_std = 10000; 10,000 double max_std = 100000000; 100,000,000

double min_max = 600000000; 600,000,000 double max_max = 1000000000; 1,000,000,000

const std::size_t max_year = 5000000; 5,000,000

const double right = 0.999; const double left = 0.001;

inline double get_rand() {

return static_cast< double >( std::rand() )

/ static_cast< double >( RAND_MAX );

}

inline void boost_( boost::math::gamma_distribution<>& d, double q ) {

double value = boost::math::quantile( d, q );

}

inline void att_bell( double alpha, double beta, double q ) {

double q_Minus1 = 1 - q; double value = 0.0; double bound = 0.0;

int which = 2; int status = 0;

cdfgam( &which

, &q , &q_Minus1 , &value , &alpha , &beta , &status , &bound );

}

int main() {

boost {

std::srand( 0 );

boost::timer timer; for( std::size_t y = 0; y < max_year; ++y ) {

if(( y % 100000 ) == 0 )

std::cout << y << std::endl;

double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std;

double alpha = mean * mean / std / std; shape parameter double beta = mean / alpha; scale parameter

boost::math::gamma_distribution<> d( alpha, beta ); boost_( d, right ); boost_( d, left );

}

std::cout << "Boost - Time elapsed: " << timer.elapsed() << "

sec" << std::endl;

}

att bell {

std::srand( 0 );

boost::timer timer; for( std::size_t y = 0; y < max_year; ++y ) {

if(( y % 100000 ) == 0 )

std::cout << y << std::endl;

double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std;

double alpha = mean * mean / std / std; shape parameter double beta = mean / alpha; scale parameter

att_bell( alpha, beta, right ); att_bell( alpha, beta, left );

}

std::cout << "ATT Bell - Time elapsed: " << timer.elapsed() <<

" sec" << std::endl;

}

return 0;

}

#10946: Add dt to system arguments

ilja.j.honkonen@… — Tue, 20 Jan 2015 17:25:03 GMT

A popular algorithm for calculating the change in velocity of a charged particle in a magnetic field (1) requires the length of the time step while integrating (dx/dt := f(x,t,dt)) and cannot be used with odeint as far as I could tell so I suggest modifying the definition of system from sys( x , dxdt , t ) to sys( x , dxdt , t , dt ). Some enable_if magic should allow all existing code using the current API to work.

(1) Equations 25 and 26 in (h)ttp://www.dtic.mil/dtic/tr/fulltext/u2/a023511.pdf

#7494: boost::replace_all is very slow on debug build when Format size is big

Thu, 11 Oct 2012 09:28:38 GMT

Method boost::replace_all(SequenceT& Input, const Range1T& Search, const Range2T& Format) on debug build takes very long time when Format size is about 300k. On call stack I can see push_front for every char.

When I use std::find and std::replace in loop it is cca 10 times faster.

I have Boost library 1.45, Visual Studio 2010, Win7 x64 SP1, 6-core CPU.

#6160: support for (istream >> array < char >)

giecrilj@… — Tue, 22 Nov 2011 00:38:37 GMT

array < T > is a replacement for T []
the standard library provides the syntax (istream >> char []) and (ostream << char const [])
Currently, (istream >> array < char >) does not mean anything
this functionality cannot be simulated even with std:: copy_n < istreambuf_iterator > without manual termination and much verbosity

My implementation

#include <boost/array.hpp>      /* for ::boost:: array */
#include <boost/version.hpp>
#if +BOOST_VERSION <= 0313720
#include <iomanip>      /* for ::std:: setw */
namespace boost
{
/* helper classes to prevent ambiguity in matching array < char > */
namespace detail_
{
/* normally, other char for every character type is char */
  template < class P_C > class other_char { public: typedef char type; };
/* but other_char is undefined for char */
  template <> class other_char < char > {};
/* class same_stream fails for istream */
  template
  < class P_S,
    class P_C = typename other_char < typename P_S:: char_type >:: type >
class same_stream { public: typedef P_S stream; }; }
/* template input */
  template < class P_C, class P_T, ::std:: size_t P_N >
  static inline ::std:: basic_istream < P_C, P_T >
&operator >>
  (::std:: basic_istream < P_C, P_T > &p_s, ::boost:: array < P_C, P_N > &p_a)
  { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); }
/* character input, disabled for type char to avoid ambiguity */
  template < class P_C, class P_T, ::std:: size_t P_N >
  static inline typename
  detail_:: same_stream
< ::std:: basic_istream < P_C, P_T > >:: stream
&operator >>
  (::std:: basic_istream < P_C, P_T > &p_s,
   ::boost:: array < char, P_N > &p_a)
  { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); }
/* template output */
  template < class P_C, class P_T, ::std:: size_t P_N >
  static inline ::std:: basic_ostream < P_C, P_T >
  &operator <<
(::std:: basic_ostream < P_C, P_T > &p_s,
 ::boost:: array < P_C, P_N > const &p_a) { return p_s << p_a. begin (); }
/* character output, disabled for type char */
  template < class P_C, class P_T, ::std:: size_t P_N >
  static inline
typename detail_:: same_stream < ::std:: basic_ostream < P_C, P_T > >:: stream
  &operator <<
(::std:: basic_ostream < P_C, P_T > &p_s,
 ::boost:: array < char, P_N > const &p_a)
{ return p_s << p_a. begin (); }}
#endif  /* BOOST_VERSION */
#include <cstdlib>      /* for EXIT_SUCCESS */
#include <cstdio>       /* for BUFSIZ */
#include <iostream>     /* for ::std:: cin */
int main ()
{ // char (&x) [+BOOST_VERSION] = 0;
#ifdef ARRAY_IN_NATIVE
/* native code */
char t [+BUFSIZ];
 return
   ::std:: cin >> ::std:: setw (+BUFSIZ) >> t && ::std:: cout << t << '\n'?
+EXIT_SUCCESS: +EXIT_FAILURE;
#else /* ARRAY_IN_NATIVE */
/* equivalent Boost code */
 ::boost:: array < char, +BUFSIZ > t;
/* check that character input compiles for wchar_t */
 (void) sizeof (std:: wcin >> t);
 return
::std:: cin >> t && ::std:: cout << t << '\n'? +EXIT_SUCCESS: +EXIT_FAILURE;
#endif /* ARRAY_IN_NATIVE */
}

#6683: find family of functions needs const Range1T& Input overloads

sairony@… — Tue, 13 Mar 2012 14:16:05 GMT

It's cumbersome to have to create named temporaries when searching using these functions. I presume the reason for why Input isn't const is due to the fact that iterator_range<> that's returned can modify Input. In the spirit of std & the rest of boost I propose an overload which returns const_iterator_range<>, which would provide the same functionality as iterator_range<> save for being able to modify the source.

#6793: Support construction from range

Sat, 14 Apr 2012 20:46:23 GMT

Could you support construction from a range and from an iterator pair? I don't know what to do when the input doesn't match the array size. If it's smaller you could default construct the rest of the array. If it's larger, you could truncate, std::terminate() or throw. Or just consider it undefined behaviour.

#7652: compile-time checked access

Tobias Loew — Tue, 06 Nov 2012 06:56:56 GMT

Since code like

boost::array<int,2> test; test[2] = 1; test[-1] = 1;

compiles correctly on some compilers (even without warnings). I suggest adding compile checked functions for static access to arrays like:

template<size_type i> reference at() {

BOOST_STATIC_ASSERT( (i < N) ); return elems[i];

}

template<size_type i> const_reference at() const {

BOOST_STATIC_ASSERT( (i < N) ); return elems[i];

}

then code like:

boost::array<int,2> test; test.at<2> = 1; test.at<-1> = 1;

would result in the expected errors.

#9287: Additional string_ref constructors

Domagoj Šarić — Tue, 22 Oct 2013 09:09:19 GMT

From:

iterator_range<Char const *>
std::vector<Char>
pair of iterators

#9576: read_until for string_ref

Wed, 15 Jan 2014 15:13:20 GMT

string_ref read_until(string_ref& is, const char* sep);

Could we have a function like this that reads until a separator, returns the part before the separator and then eats the separator? It should read and return the entire input if no separator is found.

#9577: trim_copy doesn't support string_ref

ml@… — Wed, 15 Jan 2014 19:07:55 GMT

boost::string_ref z = "  AA BB  ";
boost::string_ref b = boost::trim_copy(z);

does not compile

#10983: box-box distance doesn't seem to work with spherical coordinate systems

mdrinto@… — Thu, 29 Jan 2015 23:29:45 GMT

The "geometry distance matrix" indicates that all geometry-to-geometry distances have been implemented in 1.57. But the box-to-box distance doesn't seem to work with spherical geometries, at least with gcc 4.4.7.

One of the errors seems to be a "not yet implemented" error, so perhaps it hasn't been done yet. It does have some tricky business that a cartesian box wouldn't have, but it's a straightforward exercise in trying different cases.

I'm certainly delighted with boost::geometry's functionality as is, but it would be great if this worked. And many apologies if the mistake is mine.

See example below for problem.

#include <boost/geometry/geometry.hpp>
typedef boost::geometry::model::point<double,2,boost::geometry::cs::cartesian> cartesian_point;
typedef boost::geometry::model::point<double,2,boost::geometry::cs::spherical_equatorial<boost::geometry::degree> > spherical_point;
int main()
{
  // Works...
  boost::geometry::model::box<cartesian_point> c_box1, c_box2;
  boost::geometry::distance(c_box1,c_box2);
  // Doesn't work!
  boost::geometry::model::box<spherical_point> s_box1, s_box2;
  boost::geometry::distance(s_box1,s_box2);
  return 0;
}

#1201: Regexify the syntax highlighter

Joel de Guzman — Wed, 22 Aug 2007 23:27:56 GMT

What I'd really want is to Regex-ify the syntax highlighter and have them reconfigurable as user-supplied regex strings from configuration files. This would simplify our life a lot. There'll be only one syntax highlighter grammar and code that can accept various lexer files. Our job then is just to churn out various lexer files for different languages.

#7630: Range adaptors do not play nicely with range-based for loops

gromer@… — Fri, 02 Nov 2012 18:37:22 GMT

Consider the following C++11 code, adapted from the Range documentation:

std::vector<int> vec;
for (int val : vec | boost::adaptors::reversed
                   | boost::adaptors::uniqued) {
  // Do stuff with val
}

The behavior of this natural-seeming code is actually undefined, due to a dangling reference: per the C++ standard, it is equivalent to

{
  auto && __range = (vec | boost::adaptors::reversed
                         | boost::adaptors::uniqued);
  for ( auto __begin = __range.begin(),
             __end = __range.end();
        __begin != __end;
        ++__begin ) {
    int val = *__begin;
    // Do stuff with val
  }
}

The problem is that the value returned by the subexpression vec | boost::adaptors::reversed is a temporary, so its lifetime ends at the end of the statement containing it, namely the declaration of __range. Thus, __range is left holding a dangling reference to the range it's adapting.

The fix is for each range adaptor to use an rvalue-reference overload to detect whether the input range is a temporary, and if so, move it into the adaptor (i.e. with std::move) in order to extend its lifetime.

#10142: Range lib type_erased.cpp needs /bigobj option for mcvc and intel-win

Mon, 23 Jun 2014 11:37:00 GMT

Build of range lib on debug mode fails with msvc and icl on type_erased.cpp file. /bigobj option should be added to Jamfile.v2

# ../../../bjam --toolset=intel address-model=364 . . . file ..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp "adaptor_test\type_erased.cpp" -Fo"..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /favor:blend /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 "-I..\..\.." compile-c-c++ ..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj

call "C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat" x86_amd64 >nul

cl /Zm800 -nologo @"..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp"

type_erased.cpp C:\Users\. . .\boost_1_55_0\libs\range\test\adaptor_test\type_erased.cpp : fatal error C1128: number of sections exceeded object file format limit : compile with /bigobj

On Intel Windows 13.1, 14,0, 15.0: # ../../../bjam --toolset=intel address-model=64 . . . type_erased.cpp ..\..\..\bin.v2\libs\range\test\type_erased.test\intel-win\debug\link-static\threading-multi\adaptor_test\type_erased.obj": catastrophic error: too many segments in object file

compilation aborted for adaptor_test/type_erased.cpp (code 4)

#10332: »indexed« range adaptor's source-breaking change not mentioned in release notes

Sat, 09 Aug 2014 20:45:26 GMT

The »indexed« range adaptor has changed in v1.56.0 in source-breaking ways. I get the change and that it was necessary for range-based for loops, but this means that you now have to #if BOOST_VERSION < … around it. See this example (distilled from actual code).

Why the ticket? Because the change hasn't been mentioned at all in the release notes.

#10336: compilation error in iterator_range and unordered_map

gast128@… — Sun, 10 Aug 2014 08:07:32 GMT

I get a compilation error with vc10, iterator_range and a (const) unordered_map (the beta candidate 2 was still ok I think):

#include "stdafx.h"
#include <boost/range/iterator_range.hpp>
#include <boost/unordered_map.hpp>
int _tmain(int /*argc*/, _TCHAR* /*argv*/[])
{
   typedef boost::unordered_map<int, int>            Container;
   typedef Container::const_iterator                 ContainerIterator;
   typedef boost::iterator_range<ContainerIterator>  ContainerIteratorRange;
   const Container cnt;
   ContainerIteratorRange rng(cnt.cbegin(), cnt.cend());
   return 0;
}

This gives C2248:

'boost::unordered::iterator_detail::c_iterator<Node,ConstNodePointer>::iterator'

cannot access private typedef declared in class

etc.

Eric: Niebler:

Well, this is unfortunate. It's broken also on msvc-12 and clang trunk, but strangely not on gcc. I thought it might be due to this change in Boost.Range:

github.com/boostorg/range/commit/264017e2a9bdbfcc24517ce05f8ef96df0a8c45b

But reverting that doesn't have any effect. It works on Boost 1.55, so this is definitely a regression.

Can you please file a bug? Neil, can you take a look?

A possible fix: github.com/boostorg/range/pull/19

#10360: Since 1.56, any_range use static cast of reference instead of implicit conversion

vdavid@… — Fri, 15 Aug 2014 13:54:28 GMT

Since 1.56, when dereferencing, any_range tries to use static cast of reference instead of implicit conversion like in 1.55.

Here is an example that works with 1.55 but fails to compile with 1.56.

#include <boost/range/any_range.hpp>
#include <memory>
#include <vector>
struct A {};
int main() {
    std::vector<std::shared_ptr<A> > v;
    boost::any_range<std::shared_ptr<const A>,
                     boost::forward_traversal_tag,
                     std::shared_ptr<const A>,
                     std::ptrdiff_t> r(v);
}

#10397: compilation error with mfc-iteratior-support: ambiguous symbol

Tobias Loew — Mon, 25 Aug 2014 08:19:11 GMT

Hi,

moving parts of range_const_iterator to the namespace range_detail in file boost/range/const_iterator.hpp leads to ambiguity in /range/detail/mfc.hpp line 747:

(MSVC 11 on Windows Server 2008 R2/x64)

25>..\src\libs\boost\boost\boost/range/mfc.hpp(747): error C2872: 'range_const_iterator' : ambiguous symbol 25> could be '..\src\libs\boost\boost\boost/range/const_iterator.hpp(67) : boost::range_const_iterator' 25> or '..\src\libs\boost\boost\boost/range/const_iterator.hpp(40) : boost::range_detail::range_const_iterator' 25> ..\src\libs\boost\boost\boost/range/detail/microsoft.hpp(135) : see reference to class template instantiation 'boost::range_detail_microsoft::customization<Tag>::meta<X>' being compiled 25> with 25> [ 25> Tag=CEbsValueArray::mfc_range_base_type, 25> X=CTypedPtrArray<CObArray,EbsValue *> 25> ] 25> ..\src\libs\boost\boost\boost/range/begin.hpp(111) : see reference to class template instantiation 'boost::range_detail_microsoft::const_iterator_of<T>' being compiled 25> with 25> [ 25> T=CTypedPtrArray<CObArray,EbsValue *> 25> ] ...

The problem can be resolved by changing the name of

boost::range_detail::range_const_iterator

boost::range_detail::range_const_iterator_helper

I expect other begin/end adapters to run into the same problem.

Tobias

#10430: joined_range generates invalid range with recent gcc versions with optimization enabled

Sat, 30 Aug 2014 19:40:42 GMT

This came up in tracking down unit-test failures when trying to build a project with newer compiler versions with C++11 enabled. The unit-test in question was compiled with multiple compiler versions:

gcc 4.3.4 (without C++11 enabled): working at all optimization levels
gcc 4.7.2 (with C++11 enabled): works without optimizations, failed with -O1 or higher
gcc 4.8.4 (with C++11 enabled): works without optimizations, failed with -O1 or higher
clang 3.5.0 (recent build, with C++11 enabled): works at all optimization levels

The failure was tracked down to a use of boost::range::joined_range (Boost 1.55.0), effectively declared as:

boost::range::joined_range<boost::iterator_range<std::vector<char>::iterator, boost::iterator_range<const char*>>

In this form, the joined_range created from two valid ranges winds up "somewhere else" when the higher optimization level. I've attached a test case that demonstrates the problem. Compiled with:

g++ -std=c++11 -o join_bug join_bug.cpp

works (printing out the expected ASCII values of the joined ranges). Compiled with:

g++ -O1 -std=c++11 -o join_bug join_bug.cpp

fails (printing out zero's in my test, though the correct number of them). This test was run with the same compiler versions as above, on both Boost 1.54.0 and Boost 1.55.0, as well as gcc 4.8.2 and clang 3.4 (both for Ubuntu 14.04), with a slightly modified non-C++11 version for the gcc 4.3.4 compiler, all with the same successes/failures.

The problem goes away in all tests if the joined_range is declared like so (changing from std::vector<char>::iterator to std::vector<char>::const_iterator):

boost::range::joined_range<boost::iterator_range<std::vector<char>::const_iterator, boost::iterator_range<const char*>>

I realize this might be a gcc bug, rather than a Boost bug, but I haven't seen this reported elsewhere and would like to get the behaviour tracked since I'm only seeing problems in relation to joined_range...

#10483: boost::is_sorted docs incorrectly describe predicate

charlie@… — Tue, 09 Sep 2014 13:13:34 GMT

From the documentation

For the non-predicate version the return value is true if and only if for each adjacent elements [x,y] the expression x < y is true

and similarly for the predicate version. This isn't the case however.

From the standard [alg.sorting]

A sequence is sorted with respect to a comparator comp if for any iterator i pointing to the sequence and any non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, comp(*(i + n), *i) == false.

So the docs should say

the expression y < x is false

I get the following with g++'s underlying is_sorted():

  std::vector<int> v{1, 1};
  std::cout << boost::is_sorted(v) << std::endl; // prints 1

Reference for is_sorted at cplusplus.com [sorry not allowed to post a link] backs this up.

#10493: Since 1.56, any_range with non-reference references can cause UB

nofitserov@… — Thu, 11 Sep 2014 14:04:19 GMT

This must be related to #10360. This is a regression since 1.55.

When using any_range<T, category, T, ptrdiff_t>, mutable dereference() method returns mutable_reference_type_generator<T>::type, which becomes T&. So dereference() returns a dangling reference to an on-the-fly computed value.

See attached test case, which works with 1.55, and fails with -fsanitize=address on Clang 3.5 with 1.56.

#include <boost/range/any_range.hpp>
#include <boost/range/adaptor/transformed.hpp>
#include <cmath>
#include <iostream>
typedef boost::any_range<
    std::string,
    boost::forward_traversal_tag,
    std::string,
    std::ptrdiff_t
> range_t;
std::string f(std::string a)
{
    return a + "!";
}
int main()
{
    std::vector<std::string> v = {"a", "b"};
    range_t r = v | boost::adaptors::transformed(f);
    for (auto&& a : r)
        std::cout << a << std::endl;
    return 0;
}

#10515: Range: doc: incorrect return type

Thu, 18 Sep 2014 07:51:57 GMT

This page: http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/reference/adaptors/reference/filtered.html

reads:

Range Return Type: boost::filtered_range<decltype(rng)>

But the code shows that it has two template parameters.

namespace boost
{
    namespace range_detail
    {
        template< class P, class R >
        struct filtered_range :

Maybe other similar pages lack parameters, I don't know, but they all seem to have a single one documented.

#10865: boost::iterators::transform_iterator is not default constructible on Clang

Thu, 11 Dec 2014 09:49:25 GMT

The attached code compiles with GCC 4.9.2 and MSVC 2013, but fails with Clang 3.5.0. I've first reported it against clang, but they explained that it's actually incorrect in Boost, see clang bug #21787 (the bugtracker rejects links here).

#10988: Range filtered adapter incorrectly requires a ForwardRange

Neil Groves — Sun, 01 Feb 2015 18:26:23 GMT

The filtered Range adapter incorrectly requires a ForwardRange. A SinglePassRange should be sufficient, since it is for the Boost.Iterator filter_iterator.

#10989: strided breaks on impure traversal tags

anonymous — Mon, 02 Feb 2015 17:31:03 GMT

From http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed

[...]/boost/1.57.0/include/boost/range/iterator_range_core.hpp:216:20: error: no matching function for call to ‘boost::range_detail::strided_iterator<boost::iterators::transform_iterator<TrivialTrafo, __gnu_cxx::__normal_iterator<int*, std::vector<int> >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::iterators::random_access_traversal_tag> >::strided_iterator(boost::range_detail::strided_iterator<boost::iterators::transform_iterator<TrivialTrafo, __gnu_cxx::__normal_iterator<int*, std::vector<int> >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::random_access_traversal_tag>&)’

, m_End(End)

Problem is that make_begin_strided_iterator et al coerce the returned iterator traversal category/tag to a pure traversal tag, which doesn't necessarily agree with the Category passed to iterator_range for the base type. Fix is to use iterators::pure_iterator_traversal.

#7006: Restricted pointers support.

Domagoj Šarić — Thu, 21 Jun 2012 10:11:48 GMT

Trying to form iterator_ranges with restricted pointers causes compiler errors.

#7742: tie like functionality for ranges

philipp.moeller@… — Tue, 27 Nov 2012 11:56:41 GMT

The Graph library uses std::pair to pass ranges and this allows a nice pattern to use old-fashioned for-loops:

Graph g; boost::graph_traits<Graph>::vertex_iterator b, e; for(boost::tie(b, e) = vertices(g); b != e; ++b) {

}

This works without any modifications with pair.

The functionality would be great for all ranges as it provides users that don't want to use Boost.Range algorithms with a simple way to use their preferred style or algorithms from std.

#12158: boost::size() and friends should use an ADL barrier like boost::begin

Tue, 26 Apr 2016 21:35:42 GMT

boost::begin() and boost::end() are nicely declared in an ADL barrier namespace to avoid conflicts with code like this:

using std::begin;
auto i = begin(c);

N4280 has been accepted into C++17, which adds std::size, std::empty, and std::data. But if users attempt to use those in the same way:

using std::size;
auto s = size(c);

They may get an error. For example, if c is a std::vector<boost::shared_ptr<int>> or something, boost::size() will be found by ADL, and since it's no more specific than std::size, the call will be ambiguous.

#3483: non-null requirement in ptr_vector::transfer

Wed, 23 Sep 2009 09:40:17 GMT

http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support

is it possible to remove non-null requirement for from argument in ptr_vector::transfer method?

#2836: Request boost::optional::optional_assign_to, optional_move_to, optional_swap

aschoedl@… — Sat, 07 Mar 2009 11:25:11 GMT

I request the three member functions

template< class U > bool boost::optional<T>::optional_assign_to(U& t) const; template< class U > bool boost::optional<T>::optional_move_to(U& t); bool boost::optional<T>::optional_swap(T& t);

which, if !*this, return false, and otherwise return true and are equivalent to

t=this; t=this; and *this may have any value after the move std::swap( t, this );

#6954: property map 'put' should support move semantics

wz258@… — Wed, 30 May 2012 19:12:42 GMT

The 'put' helper function in the boost property map library should support move semantics. At the moment it takes the value to be put by const reference, I think it would be more appropriate to perfect forward it.

#12033: Boostdep misses some dependent components

edaskel@… — Mon, 29 Feb 2016 21:33:12 GMT

In creating a modular boost build for a client I found that boostdep was missing a few smaller libraries when tracing the dependencies. The library msm depends on fusion, which depends on utility, but boostdep does not list "utility" as among the depdencies of msm.

For a test case, try building libs/msm/doc/HTML/examples/SimpleTutorial.cpp using a version of Boost with only the submodules listed as dependencies of msm. It should complain about not finding boost/utility/result_of.hpp

#1836: bug in serializing wide character strings

Thu, 17 Apr 2008 21:12:21 GMT

We've discovered an issue Boost has writing and reading wide character strings (wchar_t* and std::wstrings) to non-wide character file streams (std::ifstream and std::ofstream). The issue stems from the fact that wide characters are written and read as a sequence of characters (in text_oarchive_impl.ipp and text_iarchive_impl.ipp, respectively). For text streams, an EOF character terminates the reading of a file on Windows. Some wide characters have EOF (value = 26 decimal) as one of the bytes so reading that byte causes early termination of the read. We have worked around the issue by deriving our own input and output archives from text_i|oarchive_impl<Archive> and overriding load_override() and save_override for std::wstring and wchar_t*. Our implementation just sequences through the wide characters and writes them 1 by 1 as wchar_t to the archive. This isn't very elegant and is even less readable in the file than the current implementation but does resolve the problem.

Although the test test_simple_class does test wstrings, it only uses characters 'a'-'z' which does not expose this problem.

#2326: Library does not directly support serializing data of type "foo**"

anonymous — Mon, 15 Sep 2008 03:40:34 GMT

The following example fails to compile, trying to find a .serialize() member function in an int*. Clearly the user can program around this, but serializing pointers-to-pointers seems a natural capability that should be in the library.

#include <fstream>

#include "boost/archive/text_oarchive.hpp"

class foo {

friend class boost::serialization::access;

template<class archive>

void serialize(archive& ar, const unsigned int version) {

ar & BOOST_SERIALIZATION_NVP(buff);

ar & BOOST_SERIALIZATION_NVP(ptr);

}

public:

foo() : ptr(&buff[3]) {}

int* buff[10];

int ptr;

};

int main() {

foo f;

std::ofstream serial("serial");

boost::archive::text_oarchive oa(serial);

oa << BOOST_SERIALIZATION_NVP(f);

return 0;

}

#5629: base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator

nen777w@… — Wed, 22 Jun 2011 13:29:41 GMT

MSVS 2008 The code:

#include "boost/archive/iterators/base64_from_binary.hpp"
#include "boost/archive/iterators/binary_from_base64.hpp"
#include "boost/archive/iterators/transform_width.hpp"
//typedefs
typedef  std::istreambuf_iterator<char>    my_istream_iterator;
typedef  std::ostreambuf_iterator<char>    my_ostream_iterator;
typedef boost::archive::iterators::base64_from_binary<
          boost::archive::iterators::transform_width< my_istream_iterator, 6, 8>
> bin_to_base64;
typedef boost::archive::iterators::transform_width<
    boost::archive::iterators::binary_from_base64< my_istream_iterator >, 8, 6
> base64_to_bin;
void test()
{
   {
        //INPUT FILE!!!
    std::ifstream ifs("test.zip", std::ios_base::in|std::ios_base::binary);
    std::ofstream ofs("test.arc", std::ios_base::out|std::ios_base::binary);
    std::copy(
        bin_to_base64( my_istream_iterator(ifs >> std::noskipws) ),
        bin_to_base64( my_istream_iterator() ),
        my_ostream_iterator(ofs)
    );
  }
  {
    std::ifstream ifs("test.arc", std::ios_base::in|std::ios_base::binary);
    std::ofstream ofs("test.rez", std::ios_base::out|std::ios_base::binary);
    std::copy(
        base64_to_bin( my_istream_iterator(ifs >> std::noskipws) ),
        base64_to_bin( my_istream_iterator() ),
        my_ostream_iterator(ofs)
    );
  }
}

Result: 1) If the INPUT FILE will be any of ZIP-file format. The result was:

a) _DEBUG_ERROR("istreambuf_iterator is not dereferencable"); it can be disabled or ignored b) The encoded file "test.rez" will have one superfluous byte than INPUT FILE

2) If the INPUT FILE will any other file (binary or text) all will be OK.

#5876: Serialization - tracking of non-versioned classes

ybungalobill@… — Thu, 08 Sep 2011 09:42:18 GMT

I quote a case from my workplace. The issue came up for std::vector<int>, but I use a simple struct X to reproduce the problem. See the attached file for detailed instructions.

Opened by Yakov Galka 9/8/2011 (Today) 8:31 AM Edit

The following code:

    struct X { ... };
    X x2;
    BoostLoad("SerializationBug.dat", x2);
#if FLAG
    volatile int x = 0;
    if(x)
    {
        X *x3;
        BoostLoad("this code is never executed", x3);
    }
#endif

Produces different results depending on whether FLAG == 0 or 1, although it's clear that it must not change it's behavior.

After some research it happens that the handling of tracking level is broken in boost since at least boost 1.46.1.

Assigned to Yakov Galka by Yakov Galka 9/8/2011 (Today) 8:31 AM Notified ######.

Edited by Yakov Galka 9/8/2011 (Today) 8:53 AM [Revised 11:44 AM] Edit

It happens for objects with implementation level of object_serializable. That is:

BOOST_CLASS_IMPLEMENTATION(X, boost::serialization::object_serializable)

For greater implementation level, the tracking level is read from the archive. However it still must affect the saving of objects to any archives (binary, xml, text).

If it's not clear enough, the above code reads/writes the the file correctly when FLAG == 0, but tries to load x2 as-if it's tracked when FLAG == 1.

Edited by Yakov Galka 9/8/2011 (Today) 10:38 AM Edit I've successfully reproduced this same bug in boost 1.33.1, although there it's silent (no crash, just wrong data is read). Boost serialization is broken really hard on the low-level:

basic_iserializer::tracking() decides whether the class should be tracked or not based on m_bpis value. However it can't decide this based on the information it has, since it's shared among objects serialized trough a pointer and not through a pointer.

Possible Fix: make basic_iserializer::tracking return the tracking level instead of a boolean value and let the caller decide what this tracking level means. It's a lot of work, and it may break computability with archives serialized incorrectly in 1.33.1, which happens to be possible. We are screwed anyway.

Edited by Yakov Galka 9/8/2011 (Today) 11:44 AM

Revised Yakov Galka's 8:53 AM entry from 9/8/2011

#6515: Serilaization of std::vector is broken for optimizing archives

Hartmut Kaiser — Thu, 02 Feb 2012 18:40:38 GMT

Serializing a vector<bool> causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp):

template<class Archive, class U, class Allocator>
inline void save(
    Archive & ar,
    const std::vector<U, Allocator> &t,
    const unsigned int /* file_version */,
    mpl::true_
){
    const collection_size_type count(t.size());
    ar << BOOST_SERIALIZATION_NVP(count);
    if (!t.empty())
        ar << make_array(detail::get_data(t),t.size());
}

While detail::get_data(t) is not specialized for std::vector<bool> (but it should be), and t.size() returns the number of bits stored in the vector, which is probably not what's expected either.

I'm encountering this problem with MSVC10, 64bit, Windows7.

#12741: Linker error in cross compiling with x86_64-w64-mingw32-g++

zimmermann@… — Tue, 10 Jan 2017 11:31:22 GMT

Using

using gcc : i686 : i686-w64-mingw32-g++ ;
using gcc : x86_64 : x86_64-w64-mingw32-g++ ;

in tools/build/src/user-config.jam

with x86_64-w64-mingw32-g++ (GCC) 5.3.1 20160211 and calling

./b2 toolset=gcc-x86_64 address-model=64 link=shared --stagedir=x64 target-os=windows threading=multi threadapi=win32 variant=release --with-date_time --with-filesystem --with-graph --with-math --with-program_options --with-serialization --with-system --with-thread --with-timer

gives linker errors

gcc.link.dll bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/libboost_wserialization.dll.a
bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/basic_text_wiprimitive.o:basic_text_wiprimitive.cpp:(.rdata$.refptr._ZTVN5boost7archive12codecvt_nullIwEE[.refptr._ZTVN5boost7archive12codecvt_nullIwEE]+0x0): undefined reference to `vtable for boost::archive::codecvt_null<wchar_t>'
bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/xml_wiarchive.o:xml_wiarchive.cpp:(.rdata$.refptr._ZTVN5boost7archive6detail18utf8_codecvt_facetE[.refptr._ZTVN5boost7archive6detail18utf8_codecvt_facetE]+0x0): undefined reference to `vtable for boost::archive::detail::utf8_codecvt_facet'

The 32bit version i686-w64-mingw32-g++ with toolset=gcc-i686 address-model=32 works.

#12837: Binary serialization: crash that may allow jump to attacker-controlled address

jepler@… — Tue, 14 Feb 2017 18:11:12 GMT

Using afl-fuzz on some simple programs that use boost binary and xml serialization, I have found a number of crashes and assertion failures.

To test the waters, I am beginning by filing a single bug which may allow a jump to an attacker-controlled address (i.e., the most exploitable-looking crash that has turned up so far). On my test system, it crashes on the instruction shown:

=> 0x000000000044849c <+524>:   mov    (%r12),%rax
   0x00000000004484a0 <+528>:   mov    0x20(%rbp),%r15d
   0x00000000004484a4 <+532>:   mov    %r12,%rdi
   0x00000000004484a7 <+535>:   callq  *0x10(%rax)

Notice that the value loaded at instruction <+524> is used to determine the address to call at instruction <+535>. The value of %r12 interpreted as bytes is "\0\0hive\0\0", which makes me strongly suspect that it is data from the input file (part of the 'serialization::archive' signature, masked off). Generally, the whole text of the input file would be considered under the control of the adversary.

I ran my tests on Debian Jessie amd64 with gcc version 4.9.2 (Debian 4.9.2-10). The following revisions of modularized boost were used (the tip of each master branch at the time of writing, as described by 'git describe --tags --always):

config: boost-1.62.0-57-g1abc59c
core: boost-1.61.0-59-gd753d9a
move: boost-1.63.0
serialization: boost-1.61.0-57-g62bf8fc

The commandline to compile the (non-fuzzing) version of the input test program is:

g++-4.9 -std=c++11 -Os -I serialization/include -I core/include -I move/include -I config/include -o pvec_in pvec_in.cc serialization/src/extended_type_info.cpp serialization/src/extended_type_info_typeid.cpp serialization/src/archive_exception.cpp serialization/src/basic_archive.cpp serialization/src/basic_serializer_map.cpp serialization/src/void_cast.cpp serialization/src/singleton.cpp serialization/src/basic_iarchive.cpp serialization/src/binary_iarchive.cpp serialization/src/basic_iserializer.cpp serialization/src/basic_pointer_iserializer.cpp

The breaking input file is (base-64 encoded):

FgAAAAAAAABzZXJpYWxpemF0aW9uOjphcmNoaXZlDwAECAQIAQAAAAAAAAAAAwAAAAAAAAABAAAA
AAEAAAD0/wEAAAAAAAAAAAEAAAACAAEAAAACAAAAAgAAAAAA

The source for the test harness program (pvec_in.cc) is

#include <fstream>
#include <vector>
#include <boost/shared_ptr.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/serialization/nvp.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/vector.hpp>
struct boxed_int
{
    boxed_int() : i(0) {}
    boxed_int(int i) : i(i) {}
    int i;
    template<class Archive>
    void serialize(Archive &ar, unsigned version)
    {
        ar & BOOST_SERIALIZATION_NVP(i);
    }
};
typedef boost::shared_ptr<boxed_int> pi;
void go(std::istream &is) {
    std::vector<pi> vv;
    try
    {
        boost::archive::binary_iarchive ia(is);
        ia & vv;
    }
    catch(std::exception &e) {}
}
int main(int argc, char **argv) {
    if(argc > 1) {
        std::ifstream is(argv[1]);
        go(is);
    } else {
        go(std::cin);
    }
    return 0;
}

The test harness program either takes the input file on stdin or the name of the input file as the first positional argument.

I can share details about the fuzzing setup if you like.

Thank you for taking the time to consider this issue.

--Jeff

#12913: Undefined behaviour in serialization library

John Maddock — Sun, 19 Mar 2017 18:28:47 GMT

Hi Robert,

while testing multiprecision with clang's sanitizers I found some undefined behaviour in the serialization lib. The issue can be seen by running serialization's own tests with undefined-behaviour sanitizer turned on - in fact nearly all the tests fail, but most of the failures look like issues with the tests rather than the library. However building test_binary_xml_archive with clang++ -fsanitize=address -fsanitize=undefined -fno-sanitize-recover=undefined results in:

../../../boost/archive/detail/interface_oarchive.hpp:47:16: runtime error: downcast of address 0x7ffd0a934990 which does not point to an object of type 'boost::archive::xml_oarchive'
0x7ffd0a934990: note: object is of type 'boost::archive::xml_oarchive_impl<boost::archive::xml_oarchive>'
 fd 7f 00 00  78 ae d3 9c d6 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'boost::archive::xml_oarchive_impl<boost::archive::xml_oarchive>'
SUMMARY: AddressSanitizer: undefined-behavior ../../../boost/archive/detail/interface_oarchive.hpp:47:16 in

Which looks like a genuine issue to me.

#13007: When BOOST_BIND_NO_PLACEHOLDERS is defined, framework.ipp seems to be missing an #include

bspencer@… — Wed, 03 May 2017 18:12:22 GMT

Like the summary says, I think boost/test/impl/framework.ipp should simply have one additional #include <boost/bind/placeholders.hpp> so it works when BOOST_BIND_NO_PLACEHOLDERS is defined.

#12240: Documentation for data-driven testing should explictly mention std::tuple

Tue, 31 May 2016 14:09:03 GMT

BOOST_DATA_TEST_CASE() handles ranges of std::tuples differently to ranges of other types, in that it expects to be able to expand the parts of the tuples out to multiple variables. Whether or not this is intended or just a side-effect of the implementation, I think it's a sensible behaviour. Indeed, it's quite useful to be able to supply BOOST_DATA_TEST_CASE() with pre-zipped data rather than always having to use ^.

However at the moment, this special handling of std::tuple is not documented. Hence I suggest that this be included in the documentation (possibly near the "Zips" section) or otherwise that the implementation is changed so that users' ranges of std::tuples are treated like ranges of other types (ie each tuple is expanded to one variable).

Many thanks for your work on this library.

#12902: boost test labels

dimitry — Mon, 13 Mar 2017 18:20:16 GMT

there is a tutorial about new boost test feature - the labels. but it is not clear how to run all tests in testsuite except those that are with a specific label. could you help, please?

#8498: cray.jam doesn't build .so files

alan@… — Fri, 26 Apr 2013 04:16:30 GMT

The current cray.jam file doesn't build dynamic libraries because of the lack of the -fPIC flet ag. On my my system I made the following changes (in attached patch) and was able to get ec.verything to build. I'm not a boostjam expert, I just modelled my changes on the pgi.jam and gcc.jam files. So some of these changes might not be appropriate.

#9704: b2: Compiler flavour has no flexibility for cross-compiling projects.

lukasz.forynski@… — Mon, 24 Feb 2014 20:39:19 GMT

Hi,

I've been trying hard, but it is annoying, didn't find it elsewhere and it could really be improved.

I am building my project (i.e. all of my project tree)

on 2 platforms:

Windows,
Linux,

for 3 different platforms:

Windows
Linux IA32
Linux ARM HF

Now, whilst b2 subsystem is quite flexible in specifying different types of compilers, it is not so much when using the same type of compiler, but using different versions of it.

I have managed to define it somehow, i.e. in my project_config.jam (@ home dir):

if [ os.name ] = NT
{
using gcc : : :
     <cxxflags>-std=c++11
     <cxxflags>"-include cmath"
     <cxxflags>-Wdeprecated-declarations
    ;
using gcc : armhf : arm-linux-gnueabihf-g++.exe :
     <cxxflags>-std=c++11
     <cxxflags>"-include cmath"
     <cxxflags>-Wdeprecated-declarations
    ;
}
if [ os.name ] = LINUX
{
using gcc : : :
     <cxxflags>-std=c++11
     <cxxflags>"-include cmath"
    ;
using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ :
     <cxxflags>-std=c++11
     <cxxflags>"-include cmath"
     <cxxflags>-Wdeprecated-declarations
    ;
}

But now, in every sub-project, where I'm moving files to a 'release' location, (* and whenever I need to specify copmiler-flavor specific configuration) I need to perform something like:

install copy_binaries_to_release
  :
    target_names..
  :
    <target-os>linux:<toolset-gcc:version>4.7:<location>../../release/
    <target-os>windows:<toolset>gcc-4.7.2-mingw:<location>../../release/
    <toolset-gcc:version>armhf:<location>../../release_armhf/
    <toolset>gcc-mingw-armhf:<location>../../release/
  ;

Is there a better way of doing it?

If not, then the problem (and I guess a bug) is that b2 behaves differently on different platforms, somewhat lacks of mechanism to support what I need to do (and it's not really very uncommon).

Problems:

Different toolset names when building on different OSes (and yes, I did try to specify a default flavor, but see Problem 2).

	command	toolset	flavor
gcc XA32(linux)	b2	gcc	4.7
gcc XA32(win)	b2	gcc-4.7.2-mingw	?
gcc armhf(linux)	b2 --toolset=gcc-armhf	gcc	armhf
gcc armhf(win)	b2 --toolset=gcc-armhf target-os=linux	gcc-mingw-armhf	?

Only gcc-armhf seems to achieve requested results. BUt the main issue it, that it is all different on different platforms, and both: armhf should produce compatible binaries.

BTW: is there really a need to distinguish between e.g. Cygwin and MinGW flavours if they produce the same target with the same version of compiler? If one builds from Cygwin and MinGW for the same platform: resulting executables should be compatible for the same target, so only in 'bin' build directory they can really be different (if needed), but it is unlikely that one builds both of them (target:gcc version) at the same time (like it is unlikely that I build under windows and linux at the same time).

It is not possible to specify a flavor for GCC (by explicitly giving it a name and compiler location) - because b2 is performing a version check. This check either fails, or if it does not (and default version is used) - automatic build-platform-specific flavor value is created behind the control) - probably because b2 is trying to be too clever at this.

Couldn't it leave it alone, and use flavor that was explicitly specified?

I really wish that I could specify above:

using gcc : 4.7 : <my-path-to-gcc47> ... ;
using gcc : armhf : <my-path-to-gcc47 arm hf>  ... ;

and wouldn't have to create links or worry about the build system changing/ coming up with a flavor by concatenating target name (e.g. on

b2 --toolset=gcc-armhf

with g++ (and having to hack/create symlinks to match this etc.) -

It should just accept what I specify, and use it 'as-is' (and if someone does something stupid - let them fail and fix it).

There could also be a support for something like:

import toolset ;
if [ toolset.name ] == gcc
{
  if [ toolset.flavor ] == flav_1
  {
  }
}
# and my verbosive Jamfiles could be re-written to something like:
local gcc_flavor = [ toolset.flavor ] ;
install copy_binaries_to_release
  :
    target_names..
  :
    <toolset>gcc,<flavor>4.7:<location>../../release
    <toolset>gcc,<flavor>armhf:<location>../../release_$(gcc_flavor)
    # or even to:
    <toolset>gcc:<location>../../release_$(gcc_flavor)
  ;

With a bit of guidance / advice from someone, who knows the build system well - I'm happy to help with implementing the above.

Thanks, LUkasz.

(BTW: what is the best component for build system / tools?)

#6026: phoenix block statement tries to copy objects instead of references

armagvvg@… — Fri, 14 Oct 2011 16:17:15 GMT

Let's use a simplest class, that can't be copied:

class A {
   A() {}
   A(const A&);
public:
   static A* construct() { return new A(); }
   const A& operator<<(const char *p) const { return *this; }
};
A *pa = A::construct();
A &a = *pa;

The code which use this object one time normally works:

(boost::phoenix::ref(a) << boost::phoenix::placeholders::_1)("aaa");

But when I try to use this object two times, I get an error:

(
   boost::phoenix::ref(a) << boost::phoenix::placeholders::_1
   ,boost::phoenix::ref(a) << boost::phoenix::placeholders::_1
)("aaa");

Result: 'A::A' : cannot access private member declared in class 'A'

Expecting: pass compilation and invoke "A::operator<<" two times.

Note: preprocessing directive "BOOST_SPIRIT_USE_PHOENIX_V3" was defined.

#6911: [Phoenix V3] Add tr1_result_of specialization

Michel Morin — Thu, 17 May 2012 15:01:15 GMT

To make result_of and tr1_result_of equivalent, we have to add specialization of tr1_result_of. (Boost.Phoenix V3 already has specialization of result_of.)

Also, it would be nice to avoid specialization of result_of, when we use decltype-based result_of. (As for tr1_result_of, it should be specialized even when decltype-based result_of is used.)

So, instead of

template <...>
struct result_of<F()>
{
    typedef XXXX type;
};

we should write

#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE)
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
#endif
template <...>
struct tr1_result_of<F()>
{
    typedef XXXX type;
};

A quick grep said the following files specialize result_of.

phoenix/core/actor.hpp
phoenix/function/function.hpp

#5558: Phoenix bind doesn't support bind construct

Michael Caisse — Mon, 23 May 2011 15:37:50 GMT

boost::bind uses bind<type> in situations where it cannot determine the return type. This is useful for situations where you are binding to a method with a variable argument list such as printf.

I'm not so much concerned with the bind<type> construct as I'm unsure how to bind to functions such as printf. Is there a syntax for this when utilizing Phoenix bind that I have missed?

Using boost::bind --

boost::bind<int>( &printf, "%d ", _1 )(42);

Using phoenix::bind --

phx::bind( &printf, "%d ", arg1 )(42);

results in compilation error.

#3450: [fix in git] Bug into boost::python::stl_input_iterator

micdestefano@… — Tue, 15 Sep 2009 07:53:33 GMT

I noticed that if you try to traverse more than once the range (begin,end) obtained with the stl_input_iterator, you don't get the expected results.

Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).

The problem is given by the call to the std::distance function.
If you build with -DWORK_AROUND the problem disappears, but I need to call std::distance, because it is the original class that calls it (and I prefer not to modify it simply for building a python extension).

#3673: boost python and weak_ptr from a shared_ptr argument

troy d. straszheim — Thu, 26 Nov 2009 07:22:57 GMT

if you save a weak_ptr of a shared_ptr passed to you by python, it expires almost immediately (see use of aliasing constructor in shared_ptr_from_python.hpp). See also mail from Jahn Fuchs on c++-sig list subject: boost python and weak_ptr from a shared_ptr argument

#2838: MPI Python bindings not installed correctly

lenzo@… — Mon, 09 Mar 2009 09:22:55 GMT

I've successfully built and installed boost.MPI and the Python bindings in my home dir.

Unfortunately, the Python module "mpi.so" is installed directly in the lib/-path as all the other Boost libs. When setting the PYTHONPATH to point to this location, the boost.mpi python bindings are accessible only via "import mpi" from within Python, and not via "import boost.mpi", as described in the docs at

http://www.boost.org/doc/libs/1_38_0/doc/html/mpi/python.html

I think that the Python modules should go to a sudirectory "boost" in the lib path, or it should be fixed in the documentation.

Otherwise, the boost.mpi Python bindings are gorgeous!

#4657: Boost.MPI Compile failure with Python 3

smr@… — Sat, 18 Sep 2010 18:04:50 GMT

Boost 1.44 configured to use Python 3.1 fails on two Boost.MPI files. The two fatal error messages are reproduced below, edited (see http://lists.boost.org/Archives/boost/2010/09/170659.php for the full error output).

This failure was discussed in Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595786) and Andreas Kloeckner provided a patch. See attached.

-Steve

"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -D_REENTRANT -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I"." -I"/usr/include/python3.1" -I"/usr/lib/openmpi/include" -I"/usr/lib/openmpi/include/openmpi" -c -o "bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/datatypes.o" "libs/mpi/src/python/datatypes.cpp"

libs/mpi/src/python/datatypes.cpp: In function â€˜void boost::mpi::python::export_datatypes()â€™: libs/mpi/src/python/datatypes.cpp:20: error: â€˜PyInt_Typeâ€™ was not declared in this scope In file included from ./boost/function/detail/prologue.hpp:17,

from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/mpi/python/serialize.hpp:25, from libs/mpi/src/python/datatypes.cpp:13:

...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/datatypes.o...

and

"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -D_REENTRANT -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I"." -I"/usr/include/python3.1" -I"/usr/lib/openmpi/include" -I"/usr/lib/openmpi/include/openmpi" -c -o "bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/py_environment.o" "libs/mpi/src/python/py_environment.cpp"

libs/mpi/src/python/py_environment.cpp: In function â€˜bool boost::mpi::python::mpi_init(boost::python::list, bool)â€™: libs/mpi/src/python/py_environment.cpp:53: error: cannot convert â€˜charâ€™ to â€˜wchar_tâ€™ for argument â€˜2â€™ to â€˜void PySys_SetArgv(int, wchar_t)â€™ ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/py_environment.o...

#2557: iostreams filtering_stream w/ gzip infinite loop when writing to a full drive

Mon, 01 Dec 2008 19:27:03 GMT

When a filtering_stream with a gzip_compressor is used to write to a full hard drive (i.e. insufficient free space), boost enters an infinite loop in /boost/iostreams/detail/adapter/non_blocking_adapter.hpp:41 because the write function keeps returning zero. This loop happens during the destruction of the stream. I can't seem to find a client-side workaround.

Attached is a test case, point it to a volume with zero space and give some large number of bytes. If there's insufficient space, execution hangs. Tested on mingw/winxp/gcc4.2 but seems to fail on linux/gcc as well.

#7319: Take care of c++std-lib-32966 issue

viboes — Sun, 02 Sep 2012 08:32:23 GMT

Take care of the issue raised by Howard Hinnant in

[c++std-lib-32966] Public service announcement concerning ~condition_variable_any()

"Both condition_variable and condition_variable_any are based on the POSIX pthread_cond_t. One of the very subtle behaviors of pthread_cond_t is that it is ok for a pthread_cond_t to be destroyed after all waiting threads have been signaled (assuming no new threads initiate a wait). There's even an example demonstrating this at http://www.unix.org/online.html under the specification for pthread_cond_destroy.

This subtlety is reflected in the Requires clause for the destructor of both condition_variable and condition_variable_any:

Requires: There shall be no thread blocked on *this. [Note: That is, all threads shall have been notified; they may subsequently block on the lock specified in the wait. This relaxes the usual rules, which would have required all wait calls to happen before destruction. Only the notification to unblock the wait must happen before destruction. The user must take care to ensure that no threads wait on *this once the destructor has been started, especially when the waiting threads are calling the wait functions in a loop or using the overloads of wait, wait_for, or wait_until that take a predicate. — end note ]

To be *perfectly* clear, the following is ok:

  Thread A                    Thread B
   ...                        lk.lock()
   ...                        cv.wait(lk)
  lk.lock()                      ...
  cv.notify_one()                ...
  cv.~condition_variable_any()   ...
  lk.unlock()                    ...
    ...                       finally exits cv.wait  // ok, not a data race

#7912: boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG

Viatcheslav.Sysoltsev@… — Mon, 21 Jan 2013 11:25:12 GMT

As I understood from the trac ticket https://svn.boost.org/trac/boost/ticket/7089 and sources for boost 1.50, boost::thread 1.50 implicitly adds 100 ms to the sleep time of boost::this_thread::sleep and boost::thread_sleep on linux. If the fix for 7089 cannot be backported into 1.50, the warning about broken functionality must be present in the documentation for 1.50.

#8600: wait_for_any hangs, if called with multiple copies of shared_future referencing same task

Tue, 21 May 2013 11:50:16 GMT

The following small test program shows the problem:

#include <iostream>
#include <boost/thread.hpp>
int calculate_the_answer_to_life_the_universe_and_everything()
{
    return 42;
}
int main(int argc, char* argv[])
{
   boost::packaged_task<int> pt(calculate_the_answer_to_life_the_universe_and_everything);
   boost::shared_future<int> fi1 = boost::shared_future<int>(pt.get_future());
   boost::shared_future<int> fi2 = fi1;
   boost::thread task(boost::move(pt)); // launch task on a thread
   boost::wait_for_any(fi1, fi2);
   std::cout << "Wait for any returned\n";
   return (0);
}

This program hangs infinitely in the call to boost::wait_for_any. From the docs I would expect this to work, because it's allowed to copy shared_futures. If this is not allowed, a possibility would be needed, to find out, if two shared_futures point to the same task or not. Currently wait_for_any is unusable, if there are chances, that multiple shared_futures point to the same result.

#11091: notify_all_at_thread_exit - ThreadSanitizer: data race

viboes — Mon, 09 Mar 2015 23:43:03 GMT

Test output: BenPope x86_64 Ubuntu - thread - notify_all_at_thread_exit_p / clang-linux-3.6~tsan~c14_libc++
Rev 9b68e2eec037cbcb6f96d7d54079e7e1a6a274ab / Mon, 09 Mar 2015 11:14:53 +0000
Compile [2015-03-09 15:31:08 UTC]: succeed
"clang++-3.6" -c -x c++ -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -std=c++1y -stdlib=libc++ -fsanitize=thread -O0 -fno-inline -Wall -pthread -fPIC -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -o "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o" "../libs/thread/test/sync/conditions/notify_all_at_thread_exit_pass.cpp"
Link [2015-03-09 15:31:08 UTC]: succeed
"clang++-3.6"  -Wl,-R -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-R -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-R -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-rpath-link -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-rpath-link -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-rpath-link -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -o "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p" -Wl,--start-group "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_thread.so.1.58.0" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_chrono.so.1.58.0" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_system.so.1.58.0"  -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -fsanitize=thread -lc++ -lc++abi -pthread
RmTemps /home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p
    rm -f "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o"
Run [2015-03-09 15:31:08 UTC]: fail
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c48 by thread T1:
    #0 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x00000002567a)
  Previous write of size 8 at 0x7fd7f9795c48 by main thread:
    #0 <null> <null> (0x000000000001)
  Location is stack of thread T1.
  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
SUMMARY: ThreadSanitizer: data race ??:0 boost::(anonymous namespace)::thread_proxy(void*)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Read of size 8 at 0x7d4c0000de58 by thread T1:
    #0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x0000000318e5)
    #1 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)
  Previous write of size 8 at 0x7d4c0000de58 by main thread (mutexes: write M24):
    #0 boost::shared_ptr<boost::detail::thread_data_base>::swap(boost::shared_ptr<boost::detail::thread_data_base>&) <null> (libboost_thread.so.1.58.0+0x000000031796)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::operator=(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x00000003142d)
    #2 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x000000025579)
    #3 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #4 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #5 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
  Location is heap block of size 424 at 0x7d4c0000de40 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&&)()) <null> (notify_all_at_thread_exit_p+0x0000004c6acb)
    #2 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a87)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)
  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c38 by thread T1:
    #0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x0000000318f9)
    #1 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)
  Previous write of size 8 at 0x7fd7f9795c38 by main thread:
    #0 <null> <null> (0x000000000001)
  Location is stack of thread T1.
  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Read of size 8 at 0x7d4c0000de60 by thread T1:
    #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c7696)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #2 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)
  Previous write of size 8 at 0x7d4c0000de60 by main thread (mutexes: write M24):
    #0 boost::detail::shared_count::swap(boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c71cb)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::swap(boost::shared_ptr<boost::detail::thread_data_base>&) <null> (libboost_thread.so.1.58.0+0x0000000317d6)
    #2 boost::shared_ptr<boost::detail::thread_data_base>::operator=(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x00000003142d)
    #3 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x000000025579)
    #4 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
  Location is heap block of size 424 at 0x7d4c0000de40 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&&)()) <null> (notify_all_at_thread_exit_p+0x0000004c6acb)
    #2 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a87)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)
  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c40 by thread T1:
    #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c76aa)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #2 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)
  Previous write of size 8 at 0x7fd7f9795c40 by main thread:
    #0 <null> <null> (0x000000000001)
  Location is stack of thread T1.
  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Atomic write of size 4 at 0x7d080000ef88 by thread T1:
    #0 __tsan_atomic32_fetch_add /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:613:3 (notify_all_at_thread_exit_p+0x0000004a5256)
    #1 boost::detail::atomic_increment(int _Atomic*) <null> (notify_all_at_thread_exit_p+0x0000004c77cc)
    #2 boost::detail::sp_counted_base::add_ref_copy() <null> (notify_all_at_thread_exit_p+0x0000004c7749)
    #3 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c76e6)
    #4 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #5 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)
  Previous write of size 8 at 0x7d080000ef88 by main thread (mutexes: write M24):
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::shared_count::shared_count<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6f67)
    #2 void boost::detail::sp_pointer_construct<boost::detail::thread_data_base, boost::detail::thread_data<void (*)()> >(boost::shared_ptr<boost::detail::thread_data_base>*, boost::detail::thread_data<void (*)()>*, boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c6dd0)
    #3 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6c7b)
    #4 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a93)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
  Location is heap block of size 24 at 0x7d080000ef80 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::shared_count::shared_count<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6f67)
    #2 void boost::detail::sp_pointer_construct<boost::detail::thread_data_base, boost::detail::thread_data<void (*)()> >(boost::shared_ptr<boost::detail::thread_data_base>*, boost::detail::thread_data<void (*)()>*, boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c6dd0)
    #3 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6c7b)
    #4 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a93)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)
  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)
SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::atomic_increment(int _Atomic*)
==================
No errors detected.
ThreadSanitizer: reported 6 warnings
EXIT STATUS: 66

#11499: windows - exception lock_error while intensive locking/unlocking of shared_mutex on many threads

Sat, 25 Jul 2015 23:07:06 GMT

#include "stdafx.h"
#include <boost/thread/shared_mutex.hpp>
#include <thread>
#include <mutex>
#include <shared_mutex>
#include <atomic>
#include <vector>
using MutexT = boost::shared_mutex;
using ReaderLockT = std::lock_guard<MutexT>;
using WriterLockT = std::shared_lock<MutexT>;
MutexT gMutex;
std::atomic<bool> running = true;
long reads = 0;
void read()
{
   while (running)
   {
      ReaderLockT lock(gMutex);
      std::this_thread::yield();
      ++reads;
   }
}
int main()
{
   using namespace std;
   vector<thread> threads;
   for (int i = 0; i < 256; ++i)
   {
      threads.emplace_back(thread(read));
   }
   string str;
   getline(std::cin, str);
   running = false;
   for (auto& thread : threads)
   {
      thread.join();
   }
   return 0;
}

#11550: Solaris - boost::call_once issues

lcarreon@… — Tue, 18 Aug 2015 10:46:34 GMT

I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I

get the following error messages:

"libs/thread/src/pthread/thread.cpp", line 144: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"libs/thread/src/pthread/thread.cpp", line 150: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"libs/context/src/posix/stack_traits.cpp", line 58: Error: Overloading ambiguity between "boost::call_once<void(&)(unsigned long*), unsigned long*>(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)" and "boost::call_once<void(*)(unsigned long*), unsigned long*>(boost::once_flag&, void(*)(unsigned long*), unsigned long*)".
"libs/context/src/posix/stack_traits.cpp", line 66: Error: Overloading ambiguity between "boost::call_once<void(&)(rlimit*), rlimit*>(boost::once_flag&, void(&)(rlimit*), rlimit*&&)" and "boost::call_once<void(*)(rlimit*), rlimit*>(boost::once_flag&, void(*)(rlimit*), rlimit*)".
"libs/coroutine/src/posix/stack_traits.cpp", line 56: Error: Overloading ambiguity between "boost::call_once<void(&)(unsigned long*), unsigned long*>(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)" and "boost::call_once<void(*)(unsigned long*), unsigned long*>(boost::once_flag&, void(*)(unsigned long*), unsigned long*)".
"libs/coroutine/src/posix/stack_traits.cpp", line 64: Error: Overloading ambiguity between "boost::call_once<void(&)(rlimit*), rlimit*>(boost::once_flag&, void(&)(rlimit*), rlimit*&&)" and "boost::call_once<void(*)(rlimit*), rlimit*>(boost::once_flag&, void(*)(rlimit*), rlimit*)".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".

I'm not 100% sure whether these are compiler issues or Boost compiler configuration issues thus I decided to raise this ticket.

#12104: windows - Visual Studio 2015 Update 2 RC gives out warning C4191 in thread_primitive.hpp

Wed, 30 Mar 2016 22:21:21 GMT

thread/win32/thread_primitives.hpp(312): warning C4191: 'type cast': unsafe conversion from 'boost::detail::win32::farproc_t' to 'boost::detail::win32::detail::gettickcount64_t'

Calling this function through the result pointer may cause your program to fail

#12773: WINDOWS- Boost thread 1.63.0 strict aliasing warnings

alexandre.nunes@… — Thu, 19 Jan 2017 13:34:42 GMT

I'm cross-compiling boost on Linux, having 32-bit mingw64 as a target.

I'm still seeing strict aliasing complaints on boost 1.63.0 thread/win32/shared_mutex.hpp.

As gcc 6 has even stricter aliasing rules, I'm afraid that these may be harmful, so I came up with the attached patch - which is ugly, but works.

#12795: thread library - thread_specific_ptr documentation gives obsolete recomendation

Fri, 27 Jan 2017 09:37:42 GMT

thread_specific_ptr documentation says

Though compilers often provide this facility in the form of extensions to the declaration syntax (such as _declspec(thread) or thread annotations on static or namespace-scope variable declarations), such support is non-portable, and is often limited in some way, such as only supporting POD types.

Now as we have portable thread_local in current compilers, it should be prefered to use thread_local, since thread_specific_ptr has known performance limitation.

#5947: Use CLOCK_PROCESS_CPUTIME_ID on platform providing them

viboes — Tue, 27 Sep 2011 11:30:41 GMT

The posix implementation of process real cpu clock uses the times() function. The resolution is better if we use

::clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &ts );

on platforms for which the CLOCK_PROCESS_CPUTIME_ID is supported.

#7333: Provide User-defined Literals for chrono durations on compilers supporting them

viboes — Thu, 06 Sep 2012 04:13:35 GMT

boost::chrono::duration suffixes h, min, s, ms, us, ns in namespace boost::suffixes::chrono

#7586: Add a testable_mutex

viboes — Sun, 28 Oct 2012 19:22:13 GMT

Based on Associate Mutexes with Data to Prevent Races, By Herb Sutter, May 13, 2010 - http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3

"Make our mutex testable if it isn't already.

Many mutex services (including boost::mutex) don't provide a way to ask, "Do I already hold a lock on this mutex?"

Sometimes it is needed to know if a method like is_held to be available.

This wrapper associates an arbitrary lockable type with a thread id that stores the ID of the thread that currently holds the lockable. The thread id initially holds an invalid value that means no threads own the mutex.

When we acquire a lock, we set the thread id; and when we release a lock, we reset it back to its default no id state."

#7589: Add polymorphic lockables

viboes — Sun, 28 Oct 2012 19:43:12 GMT

Mutex are generic classes that work well when generic programming. Sometimes, in a OOP context, it is useful to be able to use polymorphically any model of a lockable.

A poly_lockable class that defines the lockable interface could be added as well as an poly_lockable_adapter to make any Lockable inherit from poly_lockable.

#7595: Implement interruptible threads on top of non-interruptible threads

viboes — Sun, 28 Oct 2012 20:05:07 GMT

Once we will be able to disable thread interruption it would be great if we can provide interruptible threads on top of non-interruptible threads so that the user don't pay for what they don't use, but has yet a mechanism that allows work with interruptible and non-interruptible threads on the same executable.

See #7594 Allow to disallow thread interruptions

#7629: Implement the algorithm deadlock detection "lockdep"

anonymous — Fri, 02 Nov 2012 16:24:53 GMT

Implement the algorithm deadlock detection "lockdep" (http://ceph.com/dev-notes/lockdep-for-pthreads/)

#8094: hierarchical_mutex for lock hierarchies (to avoid deadlocks)

Sun, 17 Feb 2013 21:24:36 GMT

It would be great if boost::thread could be extended with a "hierarchical" mutex to facilitate lock hierarchies. Lock hierarchies is a construct that associates mutexes with software layer numbers, and enforces the application to only lock "downwards" in the software hierarchy [1]. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing.

An example draft implementation is attached. The attachment also includes a BOOST_THREAD_LOCAL work-around for missing "thread_local" support that should probably be moved to more neutral ground.

[1] http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163

#8273: Add externally locked streams

viboes — Mon, 11 Mar 2013 07:21:19 GMT

Based on N3354: C++ Stream Mutexes http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3354.html add thread safe streams that gets its protecting mutex externally instead of internally as in the proposal so that several streams can share the same protecting mutex.

This will be useful to take in account coherency when working with cout and cin.

#8514: Async: Add a thread_pool executor with work stealing.

viboes — Sun, 28 Apr 2013 20:57:06 GMT

See #8513 for the basic thread_pool interface

#8517: Async: Add a variadic shared_future::then

viboes — Sun, 28 Apr 2013 21:07:05 GMT

template<typename S, typename ...F>
shared_future<tuple<typename boost::result_of<F(shared_future&)>::type...>
future::then(S&, F&& func ...);

#9588: Add a parallel_invoke algorithm.

viboes — Sat, 18 Jan 2014 10:53:12 GMT

Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_invoke algorithm.