__group__,ticket,summary,component,milestone,type,created,_changetime,_description,_reporter
acharles,2628,Sequence concept incorrectly fails for basic_string,concept_check,Boost 1.56.0,Bugs,2009-01-01T03:38:48Z,2014-02-21T09:24:23Z,"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.",Joel Lathrop <jal6806@…>
acharles,7729,concept_def.hpp multiple inclusion prevention macro bug,graph,Boost 1.56.0,Bugs,2012-11-23T14:35:43Z,2014-02-21T09:35:24Z,"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
[...]
}}}
",moala@…
acharles,9939,"Patch to add ""no exceptions"" support to dynamic_bitset",dynamic_bitset,Boost 1.56.0,Patches,2014-04-22T22:09:13Z,2014-08-21T14:47:23Z,"This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc.
",Boleslaw Ciesielski <bolek@…>
agurtovoy,1215,"Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33)",mpl,To Be Determined,Bugs,2007-08-26T15:31:24Z,2010-01-25T01:20:08Z,"#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.",hfp@…
agurtovoy,1549,Boost.MPL: 'index_of' algorithm is not documented,mpl,Boost 1.36.0,Bugs,2008-01-04T02:24:33Z,2008-01-04T02:24:52Z,,Aleksey Gurtovoy
agurtovoy,2041,"MPL: more comprehensive test coverage for ""fail"" situations requiring diagnostics",mpl,Boost 1.36.0,Bugs,2008-06-23T21:07:19Z,2008-06-23T21:07:36Z,See http://thread.gmane.org/gmane.comp.lib.boost.user/36876,Aleksey Gurtovoy
andreas_huber69,4064,std::bad_cast should be thrown with BOOST_THROW_EXCEPTION,statechart,Boost 1.46.0,Bugs,2010-04-04T10:33:25Z,2010-11-06T08:11:07Z,"Also, other try/catch/throw statements should be put into appropriate #ifndef blocks.

Reported by Thomas Mathys.",Andreas Huber
andreas_huber69,6894,Highlight context forwarding in async state machine docs,statechart,To Be Determined,Bugs,2012-05-13T21:17:44Z,2013-06-09T18:03:25Z,(as reported by Sebastian Hoffmann),Andreas Huber
andreas_huber69,4063,Add debugging support,statechart,Boost 1.47.0,Feature Requests,2010-04-04T09:48:56Z,2010-11-06T08:09:26Z,See <http://thread.gmane.org/gmane.comp.lib.boost.user/52305>,Andreas Huber
andreas_huber69,4062,Write a FAQ item on why state constructors do not have access to event data,statechart,Boost 1.46.0,Tasks,2010-04-04T09:33:16Z,2013-12-15T14:42:02Z,"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",Andreas Huber
artyom,9827,"Missing support for some code page(e.g 949, 950) in windows conversion with std backend",locale,To Be Determined,Bugs,2014-04-02T09:55:42Z,2017-07-13T14:51:24Z,"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).",hucaonju@…
artyom,11848,Win32 backend bug when do wide char convert to multi byte in boost::locale,locale,To Be Determined,Bugs,2015-12-16T05:26:31Z,2015-12-16T11:47:20Z,"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).",fyrestone@…
artyom,9685,Boost.Locale does not link against static ICU on Windows,locale,To Be Determined,Feature Requests,2014-02-19T23:06:28Z,2016-12-08T14:40:25Z,"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.",stathis@…
artyom,7266,Gettext path formats.,locale,Boost 1.54.0,Patches,2012-08-23T05:47:10Z,2013-01-07T06:37:55Z,"{{{
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",166291@…
asutton,3478,Min cut interface for BGL,graph,To Be Determined,Feature Requests,2009-09-22T14:00:56Z,2010-12-08T19:44:44Z,"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.",David Doria <daviddoria@…>
asydorchuk,6063,resize does not offset rectangles (etc.) correctly or crashes,polygon,To Be Determined,Bugs,2011-10-26T21:18:46Z,2014-02-10T22:06:28Z,"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.
",dbfaken@…
asydorchuk,7984,"In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons",polygon,To Be Determined,Bugs,2013-02-05T19:25:06Z,2015-01-26T19:53:36Z,"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.",jp.charras@…
asydorchuk,11315,Compilation warnings created by boost::polygon::operators,polygon,To Be Determined,Bugs,2015-05-17T18:36:41Z,2015-07-01T17:33:16Z,"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.",lopresti@…
asydorchuk,11415,crash in processEvent_,polygon,To Be Determined,Bugs,2015-06-23T10:39:41Z,2017-08-31T09:58:54Z,"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)) {

to

	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.",mhilferink@…
awulkiew,10772,boost::geometry::within() does not recognize empty boxes,geometry,To Be Determined,Bugs,2014-11-08T19:04:31Z,2015-09-07T12:54:36Z,"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:
1. 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.
2. 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.",bromeon@…
awulkiew,11421,[geometry] rstar segmentation fault boost version 1.58.0,geometry,To Be Determined,Bugs,2015-06-25T20:23:15Z,2016-06-27T12:47:13Z,"== Notes: ==

The segmentation fault does not occur with boost version 1.55.0.[[BR]]
Discovered when upgrading from Boost 1.55.0 to Boost 1.58.0.[[BR]]
When inserting large numbers (greater than 10^4^) 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[[BR]]

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[[BR]]

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[[BR]]
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?)
}}}
",Celair <mathom.house@…>
az_sw_dude,5638,greg_month::get_month_map_ptr is not thread safe,date_time,To Be Determined,Bugs,2011-06-24T08:06:03Z,2015-03-17T16:16:58Z,"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. ",fatbone <fatbone@…>
az_sw_dude,605,Support different DST rules in timezone db based on years,date_time,,Feature Requests,2006-04-17T13:20:56Z,2010-11-28T06:27:44Z,"{{{
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.

}}}",nobody
az_sw_dude,889,Insane Dependencies,date_time,,Feature Requests,2007-04-09T23:07:09Z,2009-11-22T20:03:13Z,"{{{
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. :)
}}}",nobody
az_sw_dude,1207,"Method ""from_julian_day_number"" (class gregorian_calendar) not documented",date_time,Boost 1.51.0,Feature Requests,2007-08-23T10:19:03Z,2012-07-01T17:53:56Z,"please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ?
library: date_time

thanks

gizmo",thom_schu@…
az_sw_dude,3132,Provide conversions to time_t,date_time,,Feature Requests,2009-06-04T09:23:12Z,2012-07-01T18:11:19Z,"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.",Andrey Semashev
barendgehrels,8183,boost::geometry::intersection on two polygons returns incorrect empty intersection,geometry,To Be Determined,Bugs,2013-02-26T09:24:56Z,2013-03-17T17:47:02Z,"Hi

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

}}}
",matthewd@…
barendgehrels,8366,"""Overlay invalid input exception"" (3)",geometry,To Be Determined,Bugs,2013-04-02T08:19:24Z,2014-11-19T15:14:58Z,"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;
}
}}}",Volker Schöch <vschoech@…>
barendgehrels,8701,wrong empty polygon-linestring intersection with overlapping edges,geometry,To Be Determined,Bugs,2013-06-16T09:21:11Z,2013-08-27T21:04:08Z,"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.",aar@…
barendgehrels,11580,invalid buffer result,geometry,To Be Determined,Bugs,2015-08-25T10:00:19Z,2016-03-26T15:33:14Z,"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)))

",Marios Visvardis <visvardis.marios@…>
barendgehrels,12125,Another problems performing boolean operations on polygons with shared edges,geometry,Boost 1.63.0,Bugs,2016-04-13T22:43:43Z,2016-10-28T16:17:05Z,"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[[BR]]
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[[BR]]
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)[[BR]]
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)))",ev.mipt@…
barendgehrels,13072,boost::geometry::intersection different results for CCW and CW,geometry,To Be Determined,Bugs,2017-06-14T10:57:24Z,2017-06-14T13:13:25Z,"Hello,[[BR]]

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;
}
}}}
",kle@…
barendgehrels,13444,boost::geometry::buffer returns only partial result (regression over 1.63.0),geometry,To Be Determined,Bugs,2018-02-09T10:44:56Z,2018-02-17T17:53:03Z,"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.",andre.meyer@…
barendgehrels,13522,Invalid empty result using boost::geometry::difference,geometry,To Be Determined,Bugs,2018-04-16T09:43:01Z,2018-05-16T06:21:58Z,"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.


",lehnert@…
barendgehrels,13553,intersection gives wrong result,geometry,Boost 1.68.0,Bugs,2018-04-30T14:04:02Z,2018-05-16T06:21:26Z,"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.",marnix.berg@…
bemandawes,5734,possible handle leak in posix implementation copy_file_api,filesystem,Boost 1.48.0,Bugs,2011-07-26T04:04:07Z,2011-07-26T14:49:21Z,"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.
",alexey.kutumov@…
bemandawes,5850,last_write_time on Windows may not work on SMB2-network-mounted drive,filesystem,To Be Determined,Bugs,2011-08-31T15:22:13Z,2011-10-11T12:21:05Z,"Consider the following logical operation against a file on a network-mounted drive served over SMB2:

1. fopen(""r+b"")/fwrite/fclose a file.
2. boost::filesystem::last_write_time(file, some other specific time)
3. 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",Ken Harris <kharris@…>
bemandawes,5937,Sun C++ 5.11 Linux compilation errors: operations.cpp,filesystem,To Be Determined,Bugs,2011-09-24T12:46:46Z,2011-09-27T17:59:30Z,"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""",Peter Loibl <boost@…>
bemandawes,6188,boost directory_iterator construct throw segmentation fault,filesystem,To Be Determined,Bugs,2011-12-01T04:13:41Z,2012-01-22T15:50:02Z,"Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory.   ",anonymous
bemandawes,6638,convert_aux fails while intializing global variable,filesystem,To Be Determined,Bugs,2012-02-29T22:39:27Z,2017-04-26T16:12:09Z,"''path_traits.cpp''[[BR]]

'''convert_aux''' fails in global scope:[[BR]]

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

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

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 :( [[BR]]

Additional info: WIN 32 and 64 bit, MSVS2010[[BR]]
{{{
#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;
}
}}}
[[BR]]

P.S. If more info is required I will reply here not by email.",john doe <johndoe>
bemandawes,8388,windows_file_codecvt  should be allocated with _NEW_CRT,filesystem,To Be Determined,Bugs,2013-04-04T10:08:14Z,2014-08-02T16:16:04Z,"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.",pedro.larroy@…
bemandawes,8642,Global locale prevents from using Boost.Filesystem in global constructors and destructors,filesystem,To Be Determined,Bugs,2013-06-03T13:06:50Z,2017-03-07T09:17:41Z,"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.
",Andrey Semashev
bemandawes,9816,boost::filesystem::is_empty does not work for symbolic links on Windows,filesystem,To Be Determined,Bugs,2014-03-30T10:11:13Z,2015-09-10T13:04:38Z,"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:
[http://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks Boost::filesystem::is_empty() returns false for Symlinks]

I also created a Github project which reproduces the problem:
[https://github.com/monsdar/BoostSymLinkError Github - BoostSymLinkError]",Nils Brinkmann <monsdar+boost@…>
bemandawes,9824,boost::filesystem::is_empty() doesn't work with symlinks on Windows,filesystem,To Be Determined,Bugs,2014-04-01T09:17:13Z,2015-09-10T13:03:43Z,"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.

",michael.burr@…
bemandawes,10205,FileSystem runtime error: locale::facet::_S_create_c_locale name not valid,filesystem,Boost 1.57.0,Bugs,2014-07-16T11:59:58Z,2014-10-29T15:18:26Z,"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.

",sleary@…
bemandawes,10233,create_directories causes invalid read,filesystem,To Be Determined,Bugs,2014-07-23T13:48:27Z,2017-12-01T07:07:32Z,"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;
}
}}}
",Itay C <itay.chamiel@…>
bemandawes,10485,heap-use-after-free using C++11 range loop,filesystem,To Be Determined,Bugs,2014-09-09T16:14:17Z,2014-10-26T15:35:40Z,"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
}}}",iamvfx@…
bemandawes,10900,read_symlink fails to correctly read NTFS junctions,filesystem,To Be Determined,Bugs,2014-12-26T16:16:26Z,2017-09-22T08:59:32Z,"''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.",Benjamin Kummer-Hardt <benjamin@…>
bemandawes,2150,Inspect needs to check for missing files,inspection script,Boost 1.37.0,Feature Requests,2008-07-28T14:51:59Z,2013-01-03T19:10:48Z,"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.",Beman Dawes
bemandawes,3965,missing functions last_access_time() and last_status_change_time(),filesystem,Boost 1.43.0,Feature Requests,2010-02-28T05:35:24Z,2012-04-20T13:03:10Z,"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
",Sascha Ochsenknecht
bemandawes,4494,recursive_directory_iterator throws unexpectedly in the non-throw mode,filesystem,Boost 1.44.0,Feature Requests,2010-07-30T06:13:15Z,2013-08-31T15:54:02Z,"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.
",ttan@…
bemandawes,5896,Range directory iterators,filesystem,To Be Determined,Feature Requests,2011-09-13T22:42:39Z,2012-04-19T15:26:00Z,"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.",jmckesson@…
bemandawes,6018,Add touch() and create_file() functions,filesystem,To Be Determined,Feature Requests,2011-10-13T12:38:26Z,2011-10-13T12:38:51Z,"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.   ",Beman Dawes
bemandawes,6521,Directory listing using C++11 range-based for loops,filesystem,To Be Determined,Feature Requests,2012-02-04T18:15:21Z,2017-06-13T14:11:26Z,"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"")){
    ...
}
}}}",mustrumr97@…
bemandawes,10078,"Incomplete API with respect to file related dates (cration, modification, access)",filesystem,To Be Determined,Feature Requests,2014-05-29T09:38:36Z,2014-05-29T12:27:29Z,"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
",David Lastovicka <david@…>
bemandawes,11663,No way to query file extension without allocating memory,filesystem,To Be Determined,Feature Requests,2015-09-17T06:44:37Z,2016-09-09T18:14:22Z,"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.",matthew.chaplain@…
bemandawes,2066,Inspect needs to review generated doc files too,inspection script,Boost 1.36.0,Tasks,2008-07-03T11:16:35Z,2013-01-03T19:11:23Z,"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.",Beman Dawes
burbelgruff,5745,Use native typeof support for Oracle Solaris Studio C++ compiler,typeof,Boost 1.48.0,Feature Requests,2011-08-01T14:51:58Z,2011-08-09T09:50:47Z,"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
}}}",Maxim Kartashev <maxim.kartashev@…>
chris_kohlhoff,2875,Windows: ip::tcp::acceptor::local_endpoint() cannot be used in socket connect,asio,To Be Determined,Feature Requests,2009-03-20T06:19:50Z,2009-04-09T13:05:18Z,"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.",Benjamin Carlyle <ben.carlyle@…>
cornedbee,9991,WConversion issue in json_parser_write.hpp,property_tree,To Be Determined,Bugs,2014-05-02T06:21:11Z,2016-02-10T13:04:37Z,"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.",abhi.california@…
cornedbee,10188,Loses floating point precision on round trip,property_tree,To Be Determined,Bugs,2014-07-10T13:54:12Z,2015-01-23T12:25:23Z,"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
}}}",Magne OEstlyngen <magne+boost@…>
cornedbee,11502,narrow_encoding: -Wtype-limits warning is reported,property_tree,To Be Determined,Bugs,2015-07-26T12:28:26Z,2016-02-10T12:51:31Z,"-Wtype-limit is reported on this assert:

    char to_internal_trivial(char c) const {
        assert(c <= 0x7f); <=== Type limit
        return c;
    }
",davido
cornedbee,5658,how to get  rid of nasty compiler warning in boost/property_tree/detail/rapidxml.hpp,property_tree,To Be Determined,Tasks,2011-06-29T07:39:25Z,2014-02-14T15:10:46Z,"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
---
}}}",Dieter Stach <Dieter.Stach@…>
danieljames,8565,Lists in admonitions,quickbook,To Be Determined,Bugs,2013-05-13T11:12:38Z,2013-09-29T11:35:22Z,"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

]",thomas.moeck@…
danieljames,1558,Optional separate compilation,unordered,To Be Determined,Feature Requests,2008-01-06T18:41:53Z,2009-02-21T18:17:31Z,There are some parts of Boost.Unordered that could be compiled into a library file. Provide an option to do this.,Daniel James
danieljames,1979,More example hash functions,unordered,To Be Determined,Feature Requests,2008-06-01T10:17:27Z,2009-02-21T18:17:46Z,,Daniel James
danieljames,2448,syntax highlighting for code in documentation or website,Documentation,Website 1.X,Feature Requests,2008-10-29T19:56:48Z,2009-02-21T17:15:22Z,"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.
",hagai26@…
danieljames,8545,Can quickbook support parts and chapters as well as sections?,quickbook,To Be Determined,Feature Requests,2013-05-03T15:56:14Z,2013-05-06T16:38:17Z,"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.",John Maddock
danieljames,1175,Document quickbook's (lack of) unicode support.,quickbook,To Be Determined,Tasks,2007-08-13T11:23:21Z,2009-06-06T13:47:40Z,See http://tinyurl.com/35j57v,Joel de Guzman
danieljames,1279,Make sure multiple #import of a file imports the file only once.,quickbook,To Be Determined,Tasks,2007-09-24T06:37:48Z,2013-09-29T11:21:32Z,,Joel de Guzman
danieljames,1487,Update the writing documentation instructions,Documentation,To Be Determined,Tasks,2007-11-30T20:01:35Z,2010-06-07T22:40:00Z,The documentation (http://www.boost.org/more/writingdoc/structure.html) needs to updated and probably should be moved to the new site.,Daniel James
david.bellot,4442,Simple implementation of operator * for matrices with 0 complexity,uBLAS,To Be Determined,Patches,2010-07-15T22:47:25Z,2013-08-01T12:18:50Z,"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

",Jesse Perla <jesseperla@…>
eric_niebler,3936,[xpressive] stack overflow.,xpressive,Boost 1.43.0,Bugs,2010-02-16T14:56:20Z,2010-02-17T00:06:35Z,"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.",shewitt.au@…
eric_niebler,6992,accumulator's median feature skips 1st two data points.,accumulator,To Be Determined,Bugs,2012-06-16T01:10:15Z,2016-12-14T11:44:04Z,"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",polyactis@…
eric_niebler,3519,It should be possible to use consts as external placeholder variables.,xpressive,To Be Determined,Feature Requests,2009-10-12T15:26:05Z,2010-10-06T18:18:53Z,"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)
",ami.ganguli@…
eric_niebler,4704,Support for multicapture and balancing groups,xpressive,To Be Determined,Feature Requests,2010-10-03T09:05:25Z,2017-06-29T18:58:58Z,"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)[[BR]]
  static: (name -= stuff)

Syntax for capture conditional:
  dynamic: (?P(name)stuff)[[BR]]
  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
",erik@…
eric_niebler,6891,Add extension point to define how expressions are created from operators,proto,To Be Determined,Feature Requests,2012-05-12T16:15:55Z,2012-06-06T17:39:53Z,"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.",Mathias Gaunard
eric_niebler,4668,Conditions for operator overload in Proto (documentation),proto,To Be Determined,Tasks,2010-09-21T20:00:16Z,2010-10-06T18:18:11Z,"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.



",Roland Bock <rbock@…>
glenfe,12880,Alignment information @ PP time,align,Boost 1.65.0,Feature Requests,2017-03-01T14:42:25Z,2017-03-03T13:37:23Z,"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",Domagoj Šarić
guwi17,2692,No concepts supporting the idea of dense,uBLAS,To Be Determined,Feature Requests,2009-01-28T20:51:45Z,2009-06-18T08:01:37Z,"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).",dougrm@…
guwi17,3396,add a sparse_view class that wraps pre-allocated data into a matrix expression,uBLAS,Boost 1.42.0,Feature Requests,2009-09-03T20:16:06Z,2009-10-06T23:13:48Z,"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



",Gunter
guwi17,4033,optimized matrix products,uBLAS,Boost 1.43.0,Patches,2010-03-22T21:38:27Z,2010-03-29T06:58:56Z,"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
[[BR]]
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.
[[BR]]
den_cm is a matrix of column_major type. 
[[BR]]
The  4th column indicates the used kernel.
[[BR]]
The  5th column gives the runtime for axpy_prod2  ( clock()/1000 )
[[BR]]
The  6th column gives the runtime for sparse_prod ( clock()/1000 )
[[BR]]
The  7th column gives the runtime for axpy_prod   ( clock()/1000 )
[[BR]]
The  8th column gives the runtime for prod        ( clock()/1000 )
[[BR]]
The 10th column gives the speedup of axpy_prod2 compared to sparse_prod.
[[BR]]
The 11th column gives the speedup of axpy_prod2 compared to axpy_prod.
[[BR]]
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.",Gunter
guwi17,1915,Nested matrix products with transposes causes compiler to complain error: invalid application of ‘sizeof’,uBLAS,To Be Determined,Support Requests,2008-05-14T05:52:05Z,2008-05-14T21:56:28Z,"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:

{{{
#!cpp
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>’ 
}}}",Leo Singer <aronnax@…>
jbosch,6545,boost:::python doesn't recognize std::shared_ptr,python USE GITHUB,To Be Determined,Bugs,2012-02-11T14:03:12Z,2015-09-18T07:17:12Z,"boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr",Neal Becker <ndbecker2@…>
jewillco,3077,Reverse iterator compile-time bug in multi_array,multi_array,Boost 1.40.0,Bugs,2009-05-25T10:47:28Z,2010-06-08T22:51:47Z,"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>*)’ ",John Reid <john.reid@…>
jewillco,5636,BGL isomorphism vertex invariant interface change,graph,To Be Determined,Feature Requests,2011-06-23T22:48:35Z,2011-07-29T02:26:06Z,"(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 `v`s 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.)",Evan Driscoll <driscoll@…>
jhunold,6893,Inaccurate Radians/Degrees conversion,units,To Be Determined,Bugs,2012-05-13T10:19:17Z,2018-07-08T16:19:39Z,"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.

",pieterb@…
jking,2801,gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long),date_time,To Be Determined,Bugs,2009-02-25T20:54:04Z,2018-01-18T14:19:55Z,"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
    
  }

}}}
",pelee@…
jking,10285,local_time is not monotonic,date_time,To Be Determined,Bugs,2014-08-01T08:03:44Z,2018-01-06T15:43:11Z,"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. 


",Gaetano Mendola <mendola@…>
jking,11067,boost::gregorian::date_iterator missing postfix operators ++ and --,date_time,To Be Determined,Feature Requests,2015-03-03T16:29:10Z,2017-12-28T13:35:12Z,"/* 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 */
}",dkochin@…
johnmaddock,10103,setprecision(0) does displays too many digits of a float128,multiprecision,To Be Determined,Bugs,2014-06-07T12:38:29Z,2015-10-14T14:40:49Z,"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"";
}
}}}
",Charles Karney <charles@…>
johnmaddock,3408,gamma distribution's quantile performance,math,Boost 1.41.0,Tasks,2009-09-06T18:50:32Z,2009-10-06T17:13:28Z,"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;
}
",chhenning@…
karsten,10946,Add dt to system arguments,odeint,To Be Determined,Feature Requests,2015-01-20T17:25:03Z,2015-01-29T21:29:57Z,"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",ilja.j.honkonen@…
marshall,7494,boost::replace_all is very slow on debug build when Format size is big,string_algo,To Be Determined,Bugs,2012-10-11T09:28:38Z,2016-07-11T21:34:40Z,"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.",Jan Vonasek <jan.vonasek@…>
marshall,6160,support for (istream >> array < char >),array,To Be Determined,Feature Requests,2011-11-22T00:38:37Z,2011-11-28T17:17:25Z,"1. `array < T >` is a replacement for `T []`
1. the standard library provides the syntax `(istream >> char [])` and `(ostream << char const [])`
1. Currently, `(istream >> array < char >)` does not mean anything
1. this functionality cannot be simulated even with `std:: copy_n < istreambuf_iterator >` without manual termination and much verbosity

== My implementation ==
{{{
#!cpp

#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 */
}

}}}

",giecrilj@…
marshall,6683,find family of functions needs const Range1T& Input overloads,algorithm,To Be Determined,Feature Requests,2012-03-13T14:16:05Z,2012-03-14T08:54:17Z,"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.",sairony@…
marshall,6793,Support construction from range,array,To Be Determined,Feature Requests,2012-04-14T20:46:23Z,2012-12-17T17:31:46Z,"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.",Olaf van der Spek <olafvdspek@…>
marshall,7652,compile-time checked access,array,Boost 1.54.0,Feature Requests,2012-11-06T06:56:56Z,2013-02-12T18:11:23Z,"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.",Tobias Loew
marshall,9287,Additional string_ref constructors,utility,To Be Determined,Feature Requests,2013-10-22T09:09:19Z,2015-05-12T00:57:48Z,"From:
- iterator_range<Char const *>
- std::vector<Char>
- pair of iterators",Domagoj Šarić
marshall,9576,read_until for string_ref,algorithm,To Be Determined,Feature Requests,2014-01-15T15:13:20Z,2014-01-24T09:04:41Z,"{{{
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.",Olaf van der Spek <ml@…>
marshall,9577,trim_copy doesn't support string_ref,algorithm,To Be Determined,Feature Requests,2014-01-15T19:07:55Z,2014-03-31T20:00:27Z,"{{{
boost::string_ref z = ""  AA BB  "";
boost::string_ref b = boost::trim_copy(z);
}}}
does not compile",ml@…
mkaravel,10983,box-box distance doesn't seem to work with spherical coordinate systems,geometry,Boost 1.59.0,Bugs,2015-01-29T23:29:45Z,2015-05-11T05:25:04Z,"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;
}
}}}
",mdrinto@…
mumiee,1201,Regexify the syntax highlighter,quickbook,To Be Determined,Feature Requests,2007-08-22T23:27:56Z,2007-08-26T09:37:26Z,"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.

",Joel de Guzman
neilgroves,7630,Range adaptors do not play nicely with range-based for loops,range,To Be Determined,Bugs,2012-11-02T18:37:22Z,2016-06-02T23:18:04Z,"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.
",gromer@…
neilgroves,10142,Range lib type_erased.cpp  needs /bigobj option for mcvc and intel-win,range,To Be Determined,Bugs,2014-06-23T11:37:00Z,2014-08-25T21:12:23Z,"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)
",Elmira Semenova <elmira.a.semenova@…>
neilgroves,10332,»indexed« range adaptor's source-breaking change not mentioned in release notes,range,To Be Determined,Bugs,2014-08-09T20:45:26Z,2014-09-01T11:54:45Z,"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 [[http://boost.codepad.org/VE1QSmSz|this example]] (distilled from actual code).

Why the ticket? Because the change hasn't been mentioned at all in the [[http://www.boost.org/users/history/version_1_56_0.html|release notes]].",Moritz Bunkus <moritz@…>
neilgroves,10336,compilation error in iterator_range and unordered_map,range,To Be Determined,Bugs,2014-08-10T08:07:32Z,2015-01-31T14:52:10Z,"I get a compilation error with vc10, iterator_range and a (const)
unordered_map (the beta candidate 2 was still ok I think):

{{{#!cpp
#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

",gast128@…
neilgroves,10360,"Since 1.56, any_range use static cast of reference instead of implicit conversion",range,To Be Determined,Bugs,2014-08-15T13:54:28Z,2014-12-19T12:47:57Z,"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);
}

}}}
",vdavid@…
neilgroves,10397,compilation error with mfc-iteratior-support: ambiguous symbol,range,To Be Determined,Bugs,2014-08-25T08:19:11Z,2014-08-30T14:33:50Z,"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

to

boost::range_detail::range_const_iterator_helper

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

Tobias ",Tobias Loew
neilgroves,10430,joined_range generates invalid range with recent gcc versions with optimization enabled,range,To Be Determined,Bugs,2014-08-30T19:40:42Z,2014-09-01T11:54:18Z,"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...
",Oliver Seiler <oseiler@…>
neilgroves,10483,boost::is_sorted docs incorrectly describe predicate,range,Boost 1.58.0,Bugs,2014-09-09T13:13:34Z,2015-02-02T01:20:47Z,"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.",charlie@…
neilgroves,10493,"Since 1.56, any_range with non-reference references can cause UB",range,Boost 1.64.0,Bugs,2014-09-11T14:04:19Z,2018-03-08T08:44:24Z,"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;
}

}}}
",nofitserov@…
neilgroves,10515,Range: doc: incorrect return type,range,Boost 1.58.0,Bugs,2014-09-18T07:51:57Z,2015-02-02T01:22:17Z,"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.",akim demaille <akim@…>
neilgroves,10865,boost::iterators::transform_iterator<LambdaType> is not default constructible on Clang,range,Boost 1.58.0,Bugs,2014-12-11T09:49:25Z,2015-02-02T01:12:09Z,"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).
",Balázs Kádár <Balzs.Kdr.ext@…>
neilgroves,10988,Range filtered adapter incorrectly requires a ForwardRange,range,To Be Determined,Bugs,2015-02-01T18:26:23Z,2015-02-01T19:06:54Z,"The filtered Range adapter incorrectly requires a ForwardRange. A SinglePassRange should be sufficient, since it is for the Boost.Iterator filter_iterator.",Neil Groves
neilgroves,10989,strided breaks on impure traversal tags,range,Boost 1.58.0,Bugs,2015-02-02T17:31:03Z,2015-02-02T20:19:32Z,"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.",anonymous
neilgroves,7006,Restricted pointers support.,range,To Be Determined,Feature Requests,2012-06-21T10:11:48Z,2014-03-09T18:11:10Z,Trying to form iterator_ranges with restricted pointers causes compiler errors.,Domagoj Šarić
neilgroves,7742,tie like functionality for ranges,range,To Be Determined,Feature Requests,2012-11-27T11:56:41Z,2014-03-03T01:50:10Z,"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.
",philipp.moeller@…
neilgroves,12158,boost::size() and friends should use an ADL barrier like boost::begin,range,To Be Determined,Feature Requests,2016-04-26T21:35:42Z,2016-04-26T21:55:11Z,"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);
}}}

[http://isocpp.org/files/papers/n4280.pdf 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.",Tavian Barnes <tavianator@…>
nesotto,3483,non-null requirement in ptr_vector::transfer,ptr_container,,Feature Requests,2009-09-23T09:40:17Z,2011-03-31T20:52:16Z,"[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?",Igor Pavlov <arabesc@…>
niels_dekker,2836,"Request boost::optional<T>::optional_assign_to, optional_move_to, optional_swap",optional,Boost 1.39.0,Feature Requests,2009-03-07T11:25:11Z,2009-03-07T12:46:48Z,"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 );
",aschoedl@…
noel_belcourt,6954,property map 'put' should support move semantics,property_map,Boost 1.56.0,Bugs,2012-05-30T19:12:42Z,2014-01-27T23:48:48Z,"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.",wz258@…
pdimov,12033,Boostdep misses some dependent components,Building Boost,To Be Determined,Feature Requests,2016-02-29T21:33:12Z,2016-03-03T17:46:12Z,"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",edaskel@…
ramey,1836,bug in serializing wide character strings,serialization,To Be Determined,Bugs,2008-04-17T21:12:21Z,2010-11-29T20:32:54Z,"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.
",Jeff Faust <jeff@…>
ramey,2326,"Library does not directly support serializing data of type  ""foo**""",serialization,Boost 1.37.0,Bugs,2008-09-15T03:40:34Z,2008-09-18T15:44:22Z,"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;

       } ",anonymous
ramey,5629,base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator,serialization,To Be Determined,Bugs,2011-06-22T13:29:41Z,2014-02-19T21:27:41Z,"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.
",nen777w@…
ramey,5876,Serialization - tracking of non-versioned classes,serialization,To Be Determined,Bugs,2011-09-08T09:42:18Z,2016-04-05T10:51:57Z,"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",ybungalobill@…
ramey,6515,Serilaization of std::vector<bool> is broken for optimizing archives,serialization,To Be Determined,Bugs,2012-02-02T18:40:38Z,2012-07-15T20:35:16Z,"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.",Hartmut Kaiser
ramey,12741,Linker error in cross compiling with x86_64-w64-mingw32-g++,serialization,To Be Determined,Bugs,2017-01-10T11:31:22Z,2017-09-08T14:53:37Z,"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.",zimmermann@…
ramey,12837,Binary serialization: crash that may allow jump to attacker-controlled address,serialization,To Be Determined,Bugs,2017-02-14T18:11:12Z,2017-05-04T16:25:16Z,"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",jepler@…
ramey,12913,Undefined behaviour in serialization library,serialization,To Be Determined,Bugs,2017-03-19T18:28:47Z,2017-05-04T16:12:02Z,"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.
",John Maddock
renficiaud,13007,"When BOOST_BIND_NO_PLACEHOLDERS is defined, framework.ipp seems to be missing an #include",test,Boost 1.65.0,Bugs,2017-05-03T18:12:22Z,2017-07-07T21:22:41Z,"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.

",bspencer@…
renficiaud,12240,Documentation for data-driven testing should explictly mention std::tuple,test,To Be Determined,Feature Requests,2016-05-31T14:09:03Z,2016-09-29T14:14:53Z,"`BOOST_DATA_TEST_CASE()` handles ranges of `std::tuple`s 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::tuple`s are treated like ranges of other types (ie each tuple is expanded to one variable).

Many thanks for your work on this library.",Tony Lewis <tonyelewis@…>
renficiaud,12902,boost test labels,test,Boost 1.68.0,Support Requests,2017-03-13T18:20:16Z,2018-06-21T05:13:35Z,"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?",dimitry
rsd,8498,cray.jam doesn't build .so files,Building Boost,To Be Determined,Bugs,2013-04-26T04:16:30Z,2013-10-14T13:49:35Z,"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.",alan@…
steven_watanabe,9704,b2: Compiler flavour has no flexibility for cross-compiling projects.,build,To Be Determined,Bugs,2014-02-24T20:39:19Z,2014-04-04T22:13:25Z,"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:
1. 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).

2. 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?)



",lukasz.forynski@…
takahashi,6026,phoenix block statement tries to copy objects instead of references,phoenix,To Be Determined,Bugs,2011-10-14T16:17:15Z,2016-05-09T15:02:25Z,"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.",armagvvg@…
takahashi,6911,[Phoenix V3] Add tr1_result_of specialization,phoenix,Boost 1.67.0,Bugs,2012-05-17T15:01:15Z,2018-01-19T19:51:45Z,"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
",Michel Morin
theller,5558,Phoenix bind doesn't support bind<type> construct,phoenix,To Be Determined,Bugs,2011-05-23T15:37:50Z,2016-05-09T14:07:41Z,"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.

",Michael Caisse
troy,3450,[fix in git] Bug into boost::python::stl_input_iterator,python USE GITHUB,Boost 1.41.0,Bugs,2009-09-15T07:53:33Z,2009-09-21T07:59:44Z,"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.[[BR]]
[[BR]]
Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).[[BR]]
[[BR]]
The problem is given by the call to the `std::distance` function.[[BR]]
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).",micdestefano@…
troy,3673,boost python and weak_ptr from a shared_ptr argument,python USE GITHUB,Boost 1.43.0,Feature Requests,2009-11-26T07:22:57Z,2013-06-11T18:44:38Z,"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",troy d. straszheim
troyer,2838,MPI Python bindings not installed correctly,mpi,Boost 1.46.0,Bugs,2009-03-09T09:22:55Z,2012-11-03T23:51:39Z,"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!",lenzo@…
troyer,4657,Boost.MPI Compile failure with Python 3,mpi,To Be Determined,Bugs,2010-09-18T18:04:50Z,2013-12-03T09:18:26Z,"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... 


",smr@…
turkanis,2557,iostreams filtering_stream w/ gzip infinite loop when writing to a full drive,iostreams,Boost 1.38.0,Bugs,2008-12-01T19:27:03Z,2017-07-12T12:45:47Z,"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.",Tomasz Śniatowski <kailoran@…>
viboes,7319,Take care of c++std-lib-32966 issue,thread,To Be Determined,Bugs,2012-09-02T08:32:23Z,2012-09-02T08:41:34Z,"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
}}}

""



",viboes
viboes,7912,boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG,thread,To Be Determined,Bugs,2013-01-21T11:25:12Z,2013-06-09T20:12:37Z,"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.",Viatcheslav.Sysoltsev@…
viboes,8600,"wait_for_any hangs, if called with multiple copies of shared_future referencing same task",thread,To Be Determined,Bugs,2013-05-21T11:50:16Z,2013-06-04T06:13:38Z,"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.",Martin Apel <martin.apel@…>
viboes,11091,notify_all_at_thread_exit - ThreadSanitizer: data race,thread,To Be Determined,Bugs,2015-03-09T23:43:03Z,2015-03-09T23:43:18Z,"
{{{

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
            


}}}
",viboes
viboes,11499,windows - exception lock_error while intensive locking/unlocking of shared_mutex on many threads,thread,To Be Determined,Bugs,2015-07-25T23:07:06Z,2016-08-15T17:59:25Z,"
{{{
#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;
}


}}}
",andrew maclean <agm@…>
viboes,11550,Solaris - boost::call_once issues,thread,To Be Determined,Bugs,2015-08-18T10:46:34Z,2015-09-23T22:23:06Z,"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.
",lcarreon@…
viboes,12104,windows - Visual Studio 2015 Update 2 RC gives out warning C4191 in thread_primitive.hpp,thread,To Be Determined,Bugs,2016-03-30T22:21:21Z,2017-09-16T16:48:44Z,"
{{{
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",Shane Mathews (oneZero Financial Systems) <smathews@…>
viboes,12773,WINDOWS- Boost thread 1.63.0 strict aliasing warnings,thread,To Be Determined,Bugs,2017-01-19T13:34:42Z,2017-11-14T20:54:51Z,"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. 
",alexandre.nunes@…
viboes,12795,thread library - thread_specific_ptr documentation gives obsolete recomendation,thread,To Be Determined,Bugs,2017-01-27T09:37:42Z,2017-11-14T20:43:42Z,"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.",Oleksandr Guteniev <gutenev@…>
viboes,5947,Use CLOCK_PROCESS_CPUTIME_ID on platform providing them,chrono,To Be Determined,Feature Requests,2011-09-27T11:30:41Z,2012-06-03T14:11:46Z,"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.

",viboes
viboes,7333,Provide User-defined Literals for chrono durations on compilers supporting them,chrono,To Be Determined,Feature Requests,2012-09-06T04:13:35Z,2012-09-08T06:46:29Z,"boost::chrono::duration suffixes h, min, s, ms, us, ns in namespace boost::suffixes::chrono",viboes
viboes,7586,Add a testable_mutex,thread,,Feature Requests,2012-10-28T19:22:13Z,2014-09-05T06:11:32Z,"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.""",viboes
viboes,7589,Add polymorphic lockables,thread,,Feature Requests,2012-10-28T19:43:12Z,2014-09-05T06:11:43Z,"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.",viboes
viboes,7595,Implement interruptible threads on top of non-interruptible threads,thread,To Be Determined,Feature Requests,2012-10-28T20:05:07Z,2012-10-28T20:06:01Z,"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",viboes
viboes,7629,"Implement the algorithm deadlock detection ""lockdep""",thread,To Be Determined,Feature Requests,2012-11-02T16:24:53Z,2012-11-04T00:28:06Z,"Implement the algorithm deadlock detection ""lockdep"" (http://ceph.com/dev-notes/lockdep-for-pthreads/)",anonymous
viboes,8094,hierarchical_mutex for lock hierarchies (to avoid deadlocks),thread,To Be Determined,Feature Requests,2013-02-17T21:24:36Z,2014-10-26T20:41:49Z,"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",Fredrik Orderud <forderud@…>
viboes,8273,Add externally locked streams,thread,,Feature Requests,2013-03-11T07:21:19Z,2014-09-05T06:11:53Z,"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.",viboes
viboes,8514,Async: Add a thread_pool executor with work stealing.,thread,To Be Determined,Feature Requests,2013-04-28T20:57:06Z,2013-04-30T22:49:57Z,See #8513 for the basic thread_pool interface,viboes
viboes,8517,Async: Add a variadic shared_future::then,thread,To Be Determined,Feature Requests,2013-04-28T21:07:05Z,2013-05-28T19:09:38Z,"
{{{
template<typename S, typename ...F>
shared_future<tuple<typename boost::result_of<F(shared_future&)>::type...>
future::then(S&, F&& func ...);
}}}
",viboes
viboes,9588,Add a parallel_invoke algorithm.,thread,To Be Determined,Feature Requests,2014-01-18T10:53:12Z,2014-01-21T18:03:46Z,"Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_invoke algorithm.

The main difference is that the algorithm could take an Executor as parameter.",viboes
viboes,9589,Add a parallel_sort algorithm.,thread,To Be Determined,Feature Requests,2014-01-18T10:53:57Z,2014-01-21T18:03:55Z,"Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_sort algorithm.

The main difference is that the algorithm could take an Executor as parameter.",viboes
viboes,9590,Add a parallel_reduce algorithm.,thread,To Be Determined,Feature Requests,2014-01-18T10:55:43Z,2014-01-21T18:04:06Z,"

Base on  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_reduce algorithm.

The main difference is that the algorithm could take an Executor as parameter.
",viboes
viboes,9591,Add a parallel_for algorithm.,thread,To Be Determined,Feature Requests,2014-01-18T10:58:07Z,2014-01-22T12:07:39Z,"

Base on  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for algorithm.

The main difference is that the algorithm could take an Executor as parameter.
",viboes
viboes,9592,Add a parallel_for_each algorithm,thread,To Be Determined,Feature Requests,2014-01-18T11:01:52Z,2014-01-21T18:04:27Z,"Base on  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for_each algorithm.

The main difference is that the algorithm could take an Executor as parameter.
",viboes
viboes,9599,Add a parallel_transform algorithm,thread,To Be Determined,Feature Requests,2014-01-22T12:03:31Z,2014-01-22T12:06:12Z,"

Base on  http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_transform algorithm.

The main difference is that the algorithm could take an Executor as parameter.
",viboes
viboes,10299,Add queue iterators,thread,To Be Determined,Feature Requests,2014-08-02T15:10:58Z,2014-08-02T15:11:12Z,As for  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators add queue iterators. ,viboes
viboes,10301,Add shared_queue_front and shared_queue_back,thread,To Be Determined,Feature Requests,2014-08-02T15:20:52Z,2014-08-02T15:41:52Z,Based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#Managed add shared_queue_front and shared_queue_back.,viboes
viboes,10316,Thread: add subscription operator if the value provide it.,thread,To Be Determined,Feature Requests,2014-08-06T08:51:17Z,2014-09-29T08:19:58Z,"I would like to be able to do 


{{{
    typedef boost::synchronized_value< boost::container::flat_map<int, int> > ValueIndex;
    
    ValueIndex index;
    index[0] = 1;
}}}


and would expect that last line to be equivalent to


{{{
    auto locked_index = index.synchronize();
    (*locked_index)[0] = 1;
}}}

    

I'm not totally sure it's possible to do but it would help.",mjklaim@…
viboes,10424,future/shared_future::then() in case of continuation return an invalid future,thread,To Be Determined,Feature Requests,2014-08-30T08:50:59Z,2014-09-28T22:40:41Z,"Add this behavior to future/shared_future::then()

- In case of implicit unwrapping, the validity of the `future` returned from `then` cannot be established until after the completion of the functor passed into `then`. In such case, the resulting `future` becomes ready with an exception of type `future_error`, with an error code of `future_errc::broken_promise`. ",viboes
viboes,10550,Implicit unwrapping from then() calls,thread,To Be Determined,Feature Requests,2014-09-27T16:00:45Z,2014-09-28T22:41:28Z,Follows the Fundamental TS wording for ::then() function.,viboes
viboes,10551,Make futures returned by then()/when_all/when_any don't block.,thread,To Be Determined,Feature Requests,2014-09-27T16:25:20Z,2014-09-27T16:26:27Z,"

Follows the Fundamental TS wording for ::then()/ when_all/when_any functions.
",viboes
viboes,10610,Add unwrap shared_future constructor,thread,To Be Determined,Feature Requests,2014-10-05T10:17:57Z,2014-10-05T10:21:25Z,"Following N4123, add unwrap shared_future constructor

See also https://github.com/cplusplus/concurrency_ts/issues/58

{{{


shared_future(future<shared_future<R>>&& rhs) noexcept;

Effects:
    Constructs a shared_future object from the shared state referred to by rhs. The shared_future becomes ready when one of the following occurs:

        Both the outer future and the inner shared_future are ready. The shared_future inherits the value or the exception from the inner shared_future.
        The outer future is ready but the inner shared_future is invalid. The shared_future gets an exception of type std::future_error, with an error code of std::future_errc::broken_promise.

Postconditions:

        valid() returns the same value as rhs.valid() prior to the constructor invocation.
        valid() == true.
        rhs.valid() == false.


}}}
",viboes
viboes,10878,boost::thread::attributes -> no non-variadic-support,thread,To Be Determined,Feature Requests,2014-12-16T22:12:16Z,2016-09-02T20:55:32Z,"In terms of applying thread attributes right now the documentation describes only this signature:

template<typename Callable>
thread(attributes& attrs, Callable func);

but this does not work when variadics are not supported (leading to error: type 'boost::thread_attributes' does not provide a call operator)

Nevertheless, this temporaray way works out:

thread(attributes& attrs, boost::bind(Callable func));



",a.carot@…
viboes,10914,Add a future::notify_when_ready function,thread,To Be Determined,Feature Requests,2015-01-07T02:46:17Z,2015-01-07T02:46:29Z,This function should help to implement a generic wait_for_any on models of Future. ,viboes
viboes,10915,Change wait_for_any to work on models of Future.,thread,To Be Determined,Feature Requests,2015-01-07T02:47:53Z,2015-01-07T02:48:00Z,Using notify_when_any implement a generic wait_for_any on models of Future. ,viboes
viboes,10916,Change wait_for_all to work on models of Future.,thread,To Be Determined,Feature Requests,2015-01-07T02:48:57Z,2015-01-07T02:49:06Z,,viboes
viboes,10966,packaged_task::reset should not reuse the shared state to conform to C++11,thread,To Be Determined,Feature Requests,2015-01-24T09:51:16Z,2015-01-26T07:33:49Z,"The standard says


{{{
void reset();
Effects: as if *this = packaged_task(std::move(f)), where f is the task stored in *this. [ Note: This constructs a new shared state for *this. The old state is abandoned (30.6.4). — end note ]
Throws:
— bad_alloc if memory for the new shared state could not be allocated.
— any exception thrown by the move constructor of the task stored in the shared state. 
— future_error with an error condition of no_state if *this has no shared state.
}}}

Boost.Thread reuse the shared state.

{{{
Effects: Reset the state of the packaged_task so that it can be called again. 
}}}

",viboes
viboes,11041,Add no_unit to duration_style.,chrono,To Be Determined,Feature Requests,2015-02-17T19:08:27Z,2016-03-05T09:32:21Z,"When using Chrono I/O V2, currently there's no easy way to specify that only the numeric value of a duration without the unit should be output to a stream (equivalent of duration unit pattern ""%v""). It would be useful to add a new enumerator, say 'no_unit', to duration_style enumeration, and a corresponding stream manipulator (e.g. 'no_unit_format').",rkawulak
viboes,11052,Make all executors copyable pointing to a shared context,thread,To Be Determined,Feature Requests,2015-02-20T14:08:23Z,2015-09-29T20:18:58Z,"Ensuring that the lifetime of an executor is longer than the continuations could be hard for the user.

In particular, the tests add a sleep for to ensure it. This is not robust enough. ",viboes
viboes,11264,Add variadic lock_guard of Lockables,thread,To Be Determined,Feature Requests,2015-05-03T12:56:45Z,2015-05-14T15:59:40Z,"lock_guard works with BasicLockable.

In order the variadic version to avoid deadlock, it can work only with Lockable, as the use of lock forces it.",viboes
viboes,11552,Warning from chrono that could helpfully be suppressed,ratio,Boost 1.60.0,Feature Requests,2015-08-18T10:58:32Z,2017-08-22T20:51:01Z," Boost.Chrono is emitting warnings with GCC (5.1.0) that cannot be suppressed even using the following cxxflags in the user jamfile


{{{
      <toolset>gcc:<cxxflags>-Wno-deprecated-declarations
      <toolset>gcc:<cxxflags>-Wno-long-long
      <toolset>gcc:<cxxflags>-ftrack-macro-expansion=0 # Suppress note: in expansion of macro
}}}


and they are repeated on every compilation which is quite annoying when reading the log file.

For example:



{{{
gcc.compile.c++ ..\..\..\bin.v2\libs\timer\build\gcc-mingw-5.1.0\debug\link-static\auto_timers_construction.o
In file included from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/stdint.h:9:0,
                 from ..\..\../boost/cstdint.hpp:60,
                 from ..\..\../boost/ratio/config.hpp:13,
                 from ..\..\../boost/ratio/ratio.hpp:35,
                 from ..\..\../boost/chrono/duration.hpp:41,
                 from ..\..\../boost/chrono/chrono.hpp:11,
                 from ..\..\../boost/timer/timer.hpp:14,
                 from ..\..\..\libs\timer\src\auto_timers_construction.cpp:23:
..\..\../boost/chrono/system_clocks.hpp:77:111: warning: use of C++11 long long integer constant [-Wlong-long]
 # define BOOST_SYSTEM_CLOCK_DURATION

boost::chrono::duration<boost::int_least64_t, ratio<BOOST_RATIO_INTMAX_C(1), BOOST_RATIO_INTMAX_C(10000000)> >
                                                                                                               ^
..\..\../boost/chrono/system_clocks.hpp:77:90: note: in expansion of macro 'BOOST_RATIO_INTMAX_C'
 # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::duration<boost::int_least64_t, ratio<BOOST_RATIO_INTMAX_C(1), BOOST_RATIO_INTMAX_C(10000000)> >
}}}


and more...

It would be nice if the user would not see these (spurious?) warnings.",Paul A. Bristow
viboes,11717,Associate an Executor used to launch the continuation to a promise/packaged_task constructor.,thread,To Be Determined,Feature Requests,2015-10-10T14:55:30Z,2015-10-11T18:16:01Z,"Currently 
we have `async` function that constructs futures associated to an `Executor`. 

The `then()` member function should use this executor to launch the continuation. See #11716.

But futures can also have other sources, as e.g. a `promise` or a `packaged_task`. 
This paper proposes the addition of `Executor` aware constructors for `promise<T>` and `packaged_task<R(Args)>`
so that the continuation on the associated future make use of this executor.

We propose to: 
* Add `promise<T>::promise<T>(Executor&)` Executor aware constructor.

* Add `packaged_task<R(Args...)>::packaged_task(Executor&)` Executor aware constructor.
",viboes
viboes,11773,Extract close/closed to a more specific shutdonw-executor interface.,thread,To Be Determined,Feature Requests,2015-10-29T13:11:31Z,2015-10-29T13:13:45Z,,viboes
viboes,11774,"Extract try_executing_one, reschedule_until to a more specific reentrant executor interface.",thread,To Be Determined,Feature Requests,2015-10-29T13:12:35Z,2015-10-29T13:12:58Z,,viboes
viboes,12416,Windows: shared_mutex::state_data exceptions thrown in synthetic tests,thread,To Be Determined,Feature Requests,2016-08-28T23:21:13Z,2017-02-19T10:53:41Z,"Hi,
My name is Tomer Gal.

We have created synthetic benchmarks in which we create many threads. This causes shared_mutex to throw an exception when it has more than 2047 waiting threads due to the following limits:
        struct state_data
        {
            unsigned shared_count:11,
                shared_waiting:11,
                exclusive:1,
                upgrade:1,
                exclusive_waiting:7,
                exclusive_waiting_blocked:1;

Obviously, creating more than 2047 threads waiting for a lock is too much for 'normal' code... however, the boost library shouldn't be the limiting factor for such a usage in my opinion.

The state_data is currently limited to the size of(long) which is 32 bits, and it looks like it could be increased to 64 bits.

Could this be fixed?

Regards,
Tomer Gal, CTO at OpTeamizer

",Tomer Gal <Tomer.Gal@…>
viboes,11619,Chrono V2 IO - format tags 'unsupported'?,chrono,To Be Determined,Support Requests,2015-09-04T20:24:43Z,2015-09-11T17:02:24Z,"http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.io.ios_state_hpp.sag.set_time_fmt 

table 6.3 on the page linked above describes format tags to be used with IO. Several are listed as unsupported. There is no explanation of what 'unsupported' means. Does it mean a format string with one of those tags will cause an exception? Will the format tag be ignored? Will the entire format string fail to work? Will interation over the string stop before or after the 'unsupported' tag? More explanation would be helpful here.",steve.hickman@…
viboes,11633,chrono IO V1 may throw bad_cast,chrono,To Be Determined,Support Requests,2015-09-09T14:59:45Z,2017-08-28T05:19:54Z,"I had occurences of chrono io throwing bad_cast exceptions, which lead to backtraces like this one:


{{{
    #0  0x00007ffff54fda30 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #1  0x00007ffff554f2a2 in std::__throw_bad_cast() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #2  0x00007ffff2289bab in std::use_facet<boost::chrono::duration_punct<char> > (__loc=...) at /usr/include/c++/4.8/bits/locale_classes.tcc:137
    #3  0x00007ffff2288c61 in boost::chrono::operator<< <char, std::char_traits<char>, boost::rational<int>, boost::ratio<1l, 1l> > (os=..., d=...) at /home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include/boost/chrono/io_v1/chrono_io.hpp:210
}}}

I think the attached minimal example reproduces the issue.

Here the compile & run log using boost 1.58
{{{
$ make clean && make test
rm -f src/*.o src/chrono_io
clang++ -std=c++11 -c -g -fPIC -Iinclude -I/usr/include -o src/chrono_io.o src/chrono_io.cc
clang++ -std=c++11 -rdynamic -Lsrc -o src/chrono_io src/chrono_io.o -lboost_chrono -lboost_system -lpthread -L/usr/lib/x86_64-linux-gnu
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu ./src/chrono_io
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast
Aborted (core dumped)
Makefile:13: recipe for target 'test' failed
make: *** [test] Error 13
}}}


Here is the code around boost/include/boost/chrono/io_v1/chrono_io.hpp:210
{{{
template <class CharT, class Traits, class Rep, class Period>                  
std::basic_ostream<CharT, Traits>&                                             
operator<<(std::basic_ostream<CharT, Traits>& os, const duration<Rep, Period>& d)
{                                                                              
    typedef duration_punct<CharT> Facet;                                       
    std::locale loc = os.getloc();                                             
    if (!std::has_facet<Facet>(loc))                                           
        os.imbue(std::locale(loc, new Facet));                                 
    const Facet& f = std::use_facet<Facet>(os.getloc()); //<<<<<<< line210, throw here
    return os << d.count() << ' ' << f.template name<Period>(d.count());       
}
}}}

maybe we could avoid calling os.getloc() again at line 210 to avoid the race?",Sébastien Barthélémy <barthelemy@…>
viboes,11639,document std's vs boost's chrono::steady_clock system-wideness discrepancy,chrono,To Be Determined,Support Requests,2015-09-10T08:20:34Z,2015-10-25T23:49:58Z,"boost doc states that its steady_clock is system-wide, in doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.cpp0x.system_clocks_hpp.steady_clock
{{{
steady_clock class provides access to the system-wide steady clock.
The current time can be obtained by calling steady_clock::now().
There is no fixed relationship between values returned by
steady_clock::now() and wall-clock time. 
}}}

As far as I know, the C++11 standard does not make this requirement.

It would be good to highlight this discrepancy in the doc, especially since the doc ""Included on the C++11 Recommendation"" section let's you think that boost's chrono and std's chrono are interchangeable.",Sébastien Barthélémy <barthelemy@…>
viboes,13408,Boost Library Possible memory Leak,thread,To Be Determined,Support Requests,2018-01-19T14:30:46Z,2018-04-14T06:37:19Z,"Hi,

We have been using Boost library in the project. I've made analysis by
using Valgrind tool to be able to find possible memory leaks. According
to the result, there is a memory leak in Boost library.


{{{
==7535== 24 bytes in 1 blocks are still reachable in loss record 2 of 6
==7535==    at 0x4C2B0E0: operator new(unsigned long)
(vg_replace_malloc.c:324)
==7535==    by 0x4E430A3: boost::detail::make_external_thread_data()
(in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0)
==7535==    by 0x4E433DB: boost::detail::add_new_tss_node(void const*,
boost::shared_ptr<boost::detail::tss_cleanup_function>, void*)
(in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0)
==7535==    by 0x4E4408C: boost::detail::set_tss_data(void const*,
boost::shared_ptr<boost::detail::tss_cleanup_function>, void*, bool)
(in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0)
==7535==    by 0x54CAC0C:
boost::log::v2_mt_posix::core::add_thread_attribute(boost::log::v2_mt_posix::attribute_name const&, boost::log::v2_mt_posix::attribute const&)
}}}



It seems like the allocated memory is not deallocated, so it causes
memory leak. Here is the definition of relevant event ;


{{{
       thread_data_base* make_external_thread_data()
        {
            thread_data_base* const
me(detail::heap_new<externally_launched_thread>());
            me->self.reset(me);
            set_current_thread_data(me);
            return me;
        }


        thread_data_base* get_or_make_current_thread_data()
        {
            thread_data_base*
current_thread_data(get_current_thread_data());
            if(!current_thread_data)
            {
                current_thread_data=make_external_thread_data();
            }
            return current_thread_data;
        }

}}}

I've made some research if there is any post which states that this
event causes memory leak, but could not find any. Is there any fix for
the problem stated above? If there is any, could you please state the
relevant patch ?

Thanks in advance,

Kind Regards


",anonymous
viboes,13599,condition_variable::timed_wait never returns,thread,To Be Determined,Support Requests,2018-06-14T03:04:33Z,2018-09-11T21:29:43Z,"boost::condition_variable::timed_wait never returns if compiled with -DBOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC.

this_thread::sleep and thread::timed_join exhibit the same problem, but both these functions are documented as deprecated. However condition_variable::timed_wait is not documented as deprecated.

This can be worked around by using condition_variable::wait_for.

The following simple test program demonstrates the problem in that it hangs forever. Removing the #define makes it return after one second.

{{{
#define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC

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

int main( int argc, char* argv[] )
{
    boost::condition_variable cv;
    boost::mutex m;
    boost::mutex::scoped_lock lock( m );

    cv.timed_wait( lock, boost::posix_time::seconds( 1 ) );
    std::cout << ""wait_for has returned"" << std::endl;

    return 0;
}
}}}
",steven.cook@…
viboes,11252,make make_ready_future more efficient,thread,To Be Determined,Tasks,2015-04-29T23:37:32Z,2015-05-03T20:55:53Z,this function should be more efficient using a specific shared_state constructor.,viboes
viboes,11798,Implementation of boost::shared_mutex on POSIX is suboptimal,thread,To Be Determined,Tasks,2015-11-16T12:52:52Z,2017-12-13T02:08:35Z,"The current (as of boost 1.59) implementation of boost::shared_mutex for 'pthread' is pretty suboptimal as it's using a heavyweight mutex to guard the internal mutex state. This is more evident when shared locks are used to guard state whose access concurrency is high, due to contention on the mutex state lock (in these cases, the shared mutex is effectively exclusive). In comparison, the 'win32' implementation uses lightweight spinlocks underneath.

There are a couple options to fix this for 'pthread', e.g. using a spinlock or leveraging pthreads_rwlock. I'm happy to provide with an initial patch for this.",alex@…
viboes,12433,Make use of make_shared whenever possible in future.hpp,thread,To Be Determined,Tasks,2016-09-03T18:06:36Z,2016-09-03T18:06:47Z,Even if boost::make_shared is not aware of Boost.Move there are a lot of places in future.hpp where make shared could be used and improve the performances.,viboes
vladimir_prus,2438,gcc.jam sets LD_LIBRARY_PATH which breaks FreeBSD build,build,Boost 1.42.0,Bugs,2008-10-27T16:57:06Z,2010-01-11T17:10:44Z,"In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to:

/usr/bin:/usr/lib:/usr/lib32:/usr/lib64

Couple of points:

- /usr/bin (?) :D
- /usr/lib on FreeBSD does not contain major number libs so most if not all binaries will not pick up anything from here
- /usr/lib32 on FreeBSD DOES CONTAIN major number libs so if you are building on 32-bit this will work, HOWEVER if you are building 64-bit then this will cause failures
- /usr/lib64 does not exist on FreeBSD (I believe this is a Linux thing)

Based on the comments within gcc.jam I FEEL as do some other people (see thread reference) that if bjam is *really* going to rely on rtld then it should do so by NOT setting anything to LD_LIBRARY_PATH which many have pointed out is only to be used when the standard search path is not enough.  Setting this PATH is very dangerous and for 99% of the build cases, rtld does the right thing.

Thread:

http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html

If it is decided to set LD_LIBRARY_PATH then we need to make this OS specific and unset it for FreeBSD (or minimally add back /lib which Steven pointed out in the above thread is probably not the right solution given LD_LIBRARY_PATH's semantics).",pisymbol@…
vladimir_prus,2732,boost bjam install respects umask,build,Boost 1.38.0,Bugs,2009-02-05T21:19:52Z,2009-11-10T08:17:53Z,"Using bjam to install boost 1.37 the install procedure respects the current umask of the user.

This is not the expected behaviour. Other software install routines usually make sure to set the file modes explicitly (for example they use the unix program 'install').

Thus, if you have a umask like 0077 you have by default a boost installation which is only readable by yourself. Again, no other 'make install' or such command behaves like this.

I used this command line to install boost under Solaris 10:
./tools/jam/src/bin.solaris/bjam -sICU_PATH=/usr --user-config=user-config.jam --with-test --with-program_options address-model=64 -d3 --prefix=myprefix install

",gsauthof@…
vladimir_prus,3550,specify toolset to bootstrap.bat,Building Boost,Boost 1.46.0,Bugs,2009-10-23T15:14:14Z,2010-12-19T22:05:03Z,"Hi,

calling ""bootstrap.bat"" results in successful compilation of
boost_1_40_0\tools\jam\src\bin.ntx86_64\bjam.exe
but this is not where the bootstrap.bat expects it to be, as it only supports x86 as it seems.

BTW:  tools\jam\src\build.bat somehow finds my VS2010beta and uses that for compilation (although I'd like it to use my production VS9) and it seems I have no control of telling ""bootstrap.bat"" to use a custom toolset (this is supported by build.bat)

cheers
Chris",bielow@…
vladimir_prus,3564,bjam creates wrong library name when toolset choice is invalid,Building Boost,Boost 1.42.0,Bugs,2009-10-26T15:25:57Z,2009-11-10T07:11:18Z,"Hi,

I just called boost using
""bjam address-model=64 install --with-math link=static toolset=msvc-9 variant=debug"" which creates libraries without any VC version number:
--> libboost_math_tr1l-vc-mt-gd-1_40.lib
which should be
--> libboost_math_tr1l-vc90-mt-gd-1_40.lib

This leads to auto-linking errors.
The documentation at multiple points simply states that appending the MSVC version number to the toolset will work, however the correct syntax for the call is:
""toolset=msvc-9.0"" and not ""toolset=msvc-9""
The documentation for valid numbers is somewhat hidden as well (http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.msvc). At least the toolset docu (http://www.boost.org/doc/libs/1_40_0/more/getting_started/windows.html#identify-your-toolset) could use the above link!

So, is it possible to introduce white-lists for the toolset options to avoid this kind of error?!

",bielow@…
vladimir_prus,1094,Finding the correct library to link (feature  request for pkg-config support)h,build,Boost 1.42.0,Feature Requests,2007-07-16T17:41:27Z,2018-06-06T12:34:57Z,"This bug report is a feature request for the addition of pkg-config support to Boost, in order to provide a simple, reliable, platform-independent mechanism for discovering if the Boost libraries are installed, what they are called, where they are installed, and how to link with them.  This is currently not possible to achieve.  A detailed rationale and an example for how to implement this follow.


I make use of several Boost libraries in my schroot program
(svn://svn.debian.org/svn/buildd-tools/trunk/schroot).

This project, like many, utilises GNU Autoconf and Automake for its
build system.  I need to determine how to link with the Boost
libraries in order to build the programs in the project.  This is an
issue for many projects which want to link with a Boost library.  Note that calling bjam is not a possibility here; it may not be installed, and most projects are not using bjam, especially if boost is just one of many libraries being used.


To illustrate my problem:

 ls -l /usr/lib/libboost_regex-*.so /usr/lib/libboost_program_options-*.so
lrwxrwxrwx 1 root root 45 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-1_34.so -> libboost_program_options-gcc41-1_34.so.1.34.0
lrwxrwxrwx 1 root root 48 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-mt-1_34.so -> libboost_program_options-gcc41-mt-1_34.so.1.34.0
lrwxrwxrwx 1 root root 41 2007-07-08 11:48 /usr/lib/libboost_program_options-mt.so -> libboost_program_options-gcc41-mt-1_34.so
lrwxrwxrwx 1 root root 38 2007-07-08 11:48 /usr/lib/libboost_program_options-st.so -> libboost_program_options-gcc41-1_34.so
lrwxrwxrwx 1 root root 35 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-1_34.so -> libboost_regex-gcc41-1_34.so.1.34.0
lrwxrwxrwx 1 root root 38 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-mt-1_34.so -> libboost_regex-gcc41-mt-1_34.so.1.34.0
lrwxrwxrwx 1 root root 31 2007-07-08 11:47 /usr/lib/libboost_regex-mt.so -> libboost_regex-gcc41-mt-1_34.so
lrwxrwxrwx 1 root root 28 2007-07-08 11:47 /usr/lib/libboost_regex-st.so -> libboost_regex-gcc41-1_34.so

Unlike every other library on my system, the Boost libraries have the
compiler (gcc41) and threading model (mt|st) and so on embedded *in
the library name*.  This makes it impossible to discover in an
automatic fashion.  Since my project is free software anyone can download
and build, I don't know what the compiler/toolchain will be, let alone
what abbreviation Boost has chosen for it.  I expect that Autoconf
will set up such things appropriately; my code is relatively compiler-agnostic, but I can't predict the Boost library names without help.

The only means I have are the libboost_program_options-mt.so,
libboost_program_options-st.so (and so on for all the libraries)
symbolic links which the Debian maintainer has helpfully provided.
However, these are not portable, and are so not a good solution.  They
are, however, the only available solution at the moment.


To further show the problem I am having, this is part of my
configure.ac Autoconf template:

---configure.ac----
AC_CHECK_HEADERS([tr1/memory])

AC_CHECK_HEADERS([boost/shared_ptr.hpp],, [
  if test $ac_cv_header_tr1_memory = yes; then
    :
  else
    AC_MSG_ERROR([Boost.shared_ptr (Boost C++ Libraries) is not installed, but is required by schroot])
  fi])

AC_CHECK_HEADERS([tr1/tuple])

AC_CHECK_HEADERS([boost/tuple/tuple.hpp],, [
  if test $ac_cv_header_tr1_memory = yes; then
    :
  else
    AC_MSG_ERROR([Boost.Tuple (Boost C++ Libraries) is not installed, but is required by schroot])
  fi])

AC_CHECK_HEADERS([boost/format.hpp],, [AC_MSG_ERROR([Boost.Format (Boost C++ Libraries) is not installed, but is required by schroot])])
AC_CHECK_HEADERS([boost/program_options.hpp],, [AC_MSG_ERROR([Boost.Program_options (Boost C++ Libraries) is not installed, but is required by schroot])])
AC_CHECK_HEADERS([boost/type_traits.hpp],, [AC_MSG_ERROR([Boost.TypeTraits (Boost C++ Libraries) is not installed, but is required by schroot])])

AC_MSG_CHECKING([for boost::program_options::variables_map in -lboost_program_options-st])
saved_ldflags=""${LDFLAGS}""
LDFLAGS=""${LDFLAGS} -lboost_program_options-st""
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <boost/program_options.hpp>],
                               [boost::program_options::variables_map::variables_map dummy()])],
               [AC_MSG_RESULT([yes])
	        BOOST_LIBS=""${BOOST_LIBS} -lboost_program_options-st""],
               [AC_MSG_RESULT([no])
	        AC_MSG_FAILURE([libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot])])
LDFLAGS=""${saved_ldflags}""

AC_MSG_CHECKING([for boost::program_options::options_description::options() in -lboost_program_options-st])
saved_ldflags=""${LDFLAGS}""
LDFLAGS=""${LDFLAGS} -lboost_program_options-st""
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <boost/program_options.hpp>],
                               [boost::program_options::options_description testgrp(""test group"");
                                bool notused = testgrp.options().empty();
])],
               [AC_MSG_RESULT([yes])
                BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS=""current""],
               [AC_MSG_RESULT([no])
                BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS=""old""])
LDFLAGS=""${saved_ldflags}""
AH_TEMPLATE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, [Set if boost::program_options::options_description::options() is not available])
if test ""$BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS"" = ""old""; then
  AC_DEFINE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, 1)
fi

AC_MSG_CHECKING([for boost::regex in -lboost_regex-st])
saved_ldflags=""${LDFLAGS}""
LDFLAGS=""${LDFLAGS} -lboost_regex-st""
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <boost/regex.hpp>],
                               [boost::regex(""^foo[bar]$"")])],
               [AC_MSG_RESULT([yes])
	        BOOST_LIBS=""${BOOST_LIBS} -lboost_regex-st""],
               [AC_MSG_RESULT([no])
	        AC_MSG_FAILURE([libboost_regex (Boost C++ Libraries) is not installed, but is required by schroot])])
LDFLAGS=""${saved_ldflags}""

AC_SUBST([BOOST_LIBS])

---configure.ac----

As you can see, that's quite a bit of complexity.  It also includes
code to work around a backwards compatibility issue in
Boost.Program_options.  However, it needs to know the library name in
order to link the test code, and I'm still needing to use a
non-standard name in order to do that.


It would be great if Boost would provide a mechanism to allow such
discovery.  Such a mechanism already exists, and is called
""pkg-config"".  By installing a small file in LIBDIR/pkgconfig for each
Boost library, the pkg-config tool or PKG_CHECK_MODULES Autoconf macro
may be used to query this information.  As an example:

---- boost-regex-mt.pc ----
prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: boost-regex-mt
Description: Boost C++ Regular Expression Library (multi-threaded)
Version: 1.34.0
Libs: -L${libdir} -lboost_regex-gcc41-mt-1_34
Libs.private: -licui18n -licuuc -lrt -lm
Cflags: -I${includedir} -pthread
---- boost-regex-mt.pc ----

You can generate this from a template:

---- boost-regex-mt.pc.in ----
prefix=PREFIX
exec_prefix=EPREFIX
libdir=LIBDIR
includedir=INCLUDEDIR

Name: boost-regex-mt
Description: Boost Regular Expression Library (multi-threaded)
Version: VERSION
Libs: -L${libdir} LIBRARY_NAME
Libs.private: LIBRARY_DEPENDENCIES [for static linking]
Cflags: -I${includedir} THREAD_OPTIONS_FOR_COMPILER
---- boost-regex-mt.pc.in ----

where the capitalised names are where you would substitute in the
system- and compiler-specific options.  It looks like bjam could
probably make this a single rule all libraries could make use of.

For such a setup, all that configure script above could be mostly
reduced to

  PKG_CHECK_MODULES([boost-regex-st])
  PKG_CHECK_MODULES([boost-program-options-st])


I don't know how bjam works, but I do this with Autoconf as a file
generated by config.status, but it could also be generated by make
with a simple sed command.  I guess you could do the bjam equivalent,
whatever that might be.  I have had a look at the sources to try to
implement this, but I am afraid I lack the bjam expertise to do it.


You may find much more detailed discussion of these issues at

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539

Some of these are due to Debian-specific issues (a change to the
symlink name), but the root cause is the inability to identify the
Boost library names in an automated fashion.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.",rleigh@…
vladimir_prus,2746,Please allow specifying the library SONAME in Jamroot,build,Boost 1.39.0,Feature Requests,2009-02-11T02:11:36Z,2009-11-09T18:03:08Z,"In working on packaging the luabind library (which utilizes Boost.Jam) for Debian, I found the way that the library SONAME is passed to the linker is not ""correct.""  It seems like since the SONAME is something that should ideally be managed by the library developer, it would be good if Boost.Jam allowed the library SONAME to be specified in the Jamroot file (for operating systems that have a notion of a SONAME).

Here is the related thread from the luabind-user mailing list:

http://news.gmane.org/find-root.php?message_id=%3c20090131051842.GA15718%40connexer.com%3e

Thanks to some help from volodya in IRC, we worked up the patch from the first message in the above thread.  However, I think that some sort of configuration variable, that if set, allowed specifying the SONAME would be better.  In the absence of the SONAME being specified in the Jamroot file, the current behavior could be kept as default.",roberto@…