Boost C++ Libraries: {4} Assigned, Active Tickets by Owner https://svn.boost.org/trac10/report/4 Trac Report - List assigned tickets, group by ticket owner, sorted by priority. en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/report/4 Trac v1.4.3 #2628: Sequence concept incorrectly fails for basic_string Thu, 01 Jan 2009 03:38:48 GMT Fri, 21 Feb 2014 09:24:23 GMT <p> The Sequence concept fails when tested against basic_string (e.g. BOOST_CONCEPT_ASSERT((Sequence&lt;T&gt;)); ) 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)." </p> <p> 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. </p> Joel Lathrop <jal6806@…> https://svn.boost.org/trac10/ticket/2628 https://svn.boost.org/trac10/ticket/2628 Report #7729: concept_def.hpp multiple inclusion prevention macro bug Fri, 23 Nov 2012 14:35:43 GMT Fri, 21 Feb 2014 09:35:24 GMT <p> 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). </p> <p> As a consequence, the following warning appearing e.g. when including boost/graph/adjacency_list.hpp: </p> <pre class="wiki">"BOOST_concept" redefined [...] </pre> moala@… https://svn.boost.org/trac10/ticket/7729 https://svn.boost.org/trac10/ticket/7729 Report #9939: Patch to add "no exceptions" support to dynamic_bitset Tue, 22 Apr 2014 22:09:13 GMT Thu, 21 Aug 2014 14:47:23 GMT <p> This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc. </p> Boleslaw Ciesielski <bolek@…> https://svn.boost.org/trac10/ticket/9939 https://svn.boost.org/trac10/ticket/9939 Report #1215: Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33) Sun, 26 Aug 2007 15:31:24 GMT Mon, 25 Jan 2010 01:20:08 GMT <p> #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. </p> <p> Regard, Hans. </p> hfp@… https://svn.boost.org/trac10/ticket/1215 https://svn.boost.org/trac10/ticket/1215 Report #1549: Boost.MPL: 'index_of' algorithm is not documented Fri, 04 Jan 2008 02:24:33 GMT Fri, 04 Jan 2008 02:24:52 GMT Aleksey Gurtovoy https://svn.boost.org/trac10/ticket/1549 https://svn.boost.org/trac10/ticket/1549 Report #2041: MPL: more comprehensive test coverage for "fail" situations requiring diagnostics Mon, 23 Jun 2008 21:07:19 GMT Mon, 23 Jun 2008 21:07:36 GMT <p> See <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lib.boost.user/36876"><span class="icon">​</span>http://thread.gmane.org/gmane.comp.lib.boost.user/36876</a> </p> Aleksey Gurtovoy https://svn.boost.org/trac10/ticket/2041 https://svn.boost.org/trac10/ticket/2041 Report #4064: std::bad_cast should be thrown with BOOST_THROW_EXCEPTION Sun, 04 Apr 2010 10:33:25 GMT Sat, 06 Nov 2010 08:11:07 GMT <p> Also, other try/catch/throw statements should be put into appropriate #ifndef blocks. </p> <p> Reported by Thomas Mathys. </p> Andreas Huber https://svn.boost.org/trac10/ticket/4064 https://svn.boost.org/trac10/ticket/4064 Report #6894: Highlight context forwarding in async state machine docs Sun, 13 May 2012 21:17:44 GMT Sun, 09 Jun 2013 18:03:25 GMT <p> (as reported by Sebastian Hoffmann) </p> Andreas Huber https://svn.boost.org/trac10/ticket/6894 https://svn.boost.org/trac10/ticket/6894 Report #4063: Add debugging support Sun, 04 Apr 2010 09:48:56 GMT Sat, 06 Nov 2010 08:09:26 GMT <p> See &lt;<a class="ext-link" href="http://thread.gmane.org/gmane.comp.lib.boost.user/52305"><span class="icon">​</span>http://thread.gmane.org/gmane.comp.lib.boost.user/52305</a>&gt; </p> Andreas Huber https://svn.boost.org/trac10/ticket/4063 https://svn.boost.org/trac10/ticket/4063 Report #4062: Write a FAQ item on why state constructors do not have access to event data Sun, 04 Apr 2010 09:33:16 GMT Sun, 15 Dec 2013 14:42:02 GMT <p> The following techniques should be mentioned: </p> <ul><li>transition actions &amp; store data in an outer state </li><li>repost in transition action &amp; react in an in-state reaction </li><li>triggering_event </li></ul> Andreas Huber https://svn.boost.org/trac10/ticket/4062 https://svn.boost.org/trac10/ticket/4062 Report #9827: Missing support for some code page(e.g 949, 950) in windows conversion with std backend Wed, 02 Apr 2014 09:55:42 GMT Thu, 13 Jul 2017 14:51:24 GMT <p> 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: </p> <pre class="wiki">// 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&lt;char&gt;("abcdefg", loc); </pre><p> 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): </p> <pre class="wiki">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; } } </pre><p> 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. </p> <p> For a quick fix, I suggest adding the missing code page to the table: </p> <pre class="wiki">{ "cp949", 949, 0 }, // Korean { "uhc", 949, 0 }, // From "iconv -l" { "windows949", 949, 0 }, // Korean // "big5" already in the table { "windows950", 950, 0 }, // TC, big5 </pre><p> 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: </p> <pre class="wiki">--- 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-&gt;codepage; } else { return -1; } } + if(ptr==end &amp;&amp; charset.size()&gt;7 &amp;&amp; charset.substr(0,7)=="windows") { + int cp = atoi(charset.substr(7).c_str()); + if(IsValidCodePage(cp)) { + return cp; + } + } return -1; } template&lt;typename CharType&gt; bool validate_utf16(CharType const *str,unsigned len) </pre><p> This piece of code directly parses and validates the encoding string. The concern is that the call to <a class="missing wiki">IsValidCodePage</a> may decrease the performance(not tested). </p> hucaonju@… https://svn.boost.org/trac10/ticket/9827 https://svn.boost.org/trac10/ticket/9827 Report #11848: Win32 backend bug when do wide char convert to multi byte in boost::locale Wed, 16 Dec 2015 05:26:31 GMT Wed, 16 Dec 2015 11:47:20 GMT <p> 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 <a class="missing wiki">WideCharToMultiByte</a> called. This will make n is zero, and the second <a class="missing wiki">WideCharToMultiByte</a> call will make the program crash. </p> <p> 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: </p> <blockquote> <p> 50220 50221 50222 50225 50227 50229 57002 through 57011 65000 (UTF-7) 42 (Symbol) </p> </blockquote> <blockquote> <p> It is still true as of Windows 8 &amp; 10: if you try to call </p> </blockquote> <p> BOOL bVal = FALSE; </p> <p> <a class="missing wiki">WideCharToMultiByte</a>(50220, 0, L"asdf", 4, NULL, 0, NULL, &amp;bVal); </p> <p> You'll get 0 with <a class="missing wiki">GetLastError</a> 87 (ERROR_INVALID_PARAMETER). </p> fyrestone@… https://svn.boost.org/trac10/ticket/11848 https://svn.boost.org/trac10/ticket/11848 Report #9685: Boost.Locale does not link against static ICU on Windows Wed, 19 Feb 2014 23:06:28 GMT Thu, 08 Dec 2016 14:40:25 GMT <p> 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? </p> <p> I would be willing to write that support if there is a bit of guidance on how to go about it in the Jamfile. </p> stathis@… https://svn.boost.org/trac10/ticket/9685 https://svn.boost.org/trac10/ticket/9685 Report #7266: Gettext path formats. Thu, 23 Aug 2012 05:47:10 GMT Mon, 07 Jan 2013 06:37:55 GMT <pre class="wiki">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. </pre><p> 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: <a class="ext-link" href="http://lists.boost.org/Archives/boost/2012/08/195789.php"><span class="icon">​</span>http://lists.boost.org/Archives/boost/2012/08/195789.php</a> </p> 166291@… https://svn.boost.org/trac10/ticket/7266 https://svn.boost.org/trac10/ticket/7266 Report #3478: Min cut interface for BGL Tue, 22 Sep 2009 14:00:56 GMT Wed, 08 Dec 2010 19:44:44 GMT <p> 1) The max flow can be obtained with: (any of the max_flow algorithms, kolmogorov is just used as an example) </p> <p> double flow = kolmogorov_max_flow(g, <a class="missing wiki">SourceNode</a>, <a class="missing wiki">SinkNode</a>); </p> <p> 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&lt;unsigned int&gt; <a class="missing wiki">GetSourceSideNodes</a>(); <em>return the IDs of the nodes on the source side std::vector&lt;unsigned int&gt; <a class="missing wiki">GetSinkSideNodes</a>();</em>return the IDs of the nodes on the sink side std::vector&lt;unsigned int&gt; <a class="missing wiki">GetCutEdges</a>(); <em> return the IDs of the edges which were cut </em></p> <p> 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. </p> <p> 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. </p> <p> 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. </p> <p> 5) VERY simple examples (actually constructing a graph (not reading it from file) with &lt; 10 nodes) should be provided to demonstrate all of these cases. </p> David Doria <daviddoria@…> https://svn.boost.org/trac10/ticket/3478 https://svn.boost.org/trac10/ticket/3478 Report #6063: resize does not offset rectangles (etc.) correctly or crashes Wed, 26 Oct 2011 21:18:46 GMT Mon, 10 Feb 2014 22:06:28 GMT <p> When using the 'corner_fill_arc' parameter to polygon_set_concept&lt;T&gt;::resize(), a minkowski sum using a polygonalized circle is used to get the offset shape. </p> <p> A symptom of the problem is demonstrated by the following code: </p> <pre class="wiki"> { polygon_set_data&lt;int&gt; ps1, ps2, ps3; ps1.insert(rectangle_data&lt;int&gt;(0, 0, 50, 50)); ps2.insert(rectangle_data&lt;int&gt;(0, 0, 50, 50)); ps3.insert(rectangle_data&lt;int&gt;(0, 0, 50, 50)); std::cout &lt;&lt; "rect before resize: " &lt;&lt; ps1 &lt;&lt; std::endl; ps1.resize(6, true, 0); ps2.resize(6, true, 5); ps3.resize(6, true, 6); rectangle_data&lt;int&gt; ps1_extents, ps2_extents, ps3_extents; extents(ps1_extents, ps1); extents(ps2_extents, ps2); extents(ps3_extents, ps3); std::cout &lt;&lt; "extents of resized rect with '0' (4) segments in circle: " &lt;&lt; ps1_extents &lt;&lt; std::endl; std::cout &lt;&lt; "extents of resized rect with 5 segments in circle: " &lt;&lt; ps2_extents &lt;&lt; std::endl; std::cout &lt;&lt; "extents of resized rect with 6 segments in circle: " &lt;&lt; ps3_extents &lt;&lt; std::endl; } </pre><p> If I put this at the end of the gtl_boost_unit_test.cpp, I get the following output: </p> <pre class="wiki">rect before resize: Polygon Set Data { &lt;0 0, 50 0&gt;:1 &lt;50 0, 50 50&gt;:-1 &lt;0 50, 50 50&gt;:-1 &lt;0 0, 0 50&gt;: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 </pre><p> This shows that the extents of the offset shape vary as the number of segments does - which should not be the case! </p> <p> The extents should all be: -6 56 -6 56 </p> <hr /> <p> 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. </p> <p> 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) </p> <hr /> <p> 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. </p> <p> 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. </p> <p> 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). </p> <p> This would only affect corners, instead of the whole shape. </p> dbfaken@… https://svn.boost.org/trac10/ticket/6063 https://svn.boost.org/trac10/ticket/6063 Report #7984: In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons Tue, 05 Feb 2013 19:25:06 GMT Mon, 26 Jan 2015 19:53:36 GMT <p> 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. </p> <p> In the sample which calculate the difference between 2 polygon sets, there are 2 polygon sets: one creates no polygon, and the other crashes. </p> <p> 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). </p> <p> 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) </p> <p> Thanks to the developpers. </p> jp.charras@… https://svn.boost.org/trac10/ticket/7984 https://svn.boost.org/trac10/ticket/7984 Report #11315: Compilation warnings created by boost::polygon::operators Sun, 17 May 2015 18:36:41 GMT Wed, 01 Jul 2015 17:33:16 GMT <p> 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. </p> <p> This took me a little while to track down, since the error occurs on a call to "*" using primitive types (!). </p> <p> 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. </p> lopresti@… https://svn.boost.org/trac10/ticket/11315 https://svn.boost.org/trac10/ticket/11315 Report #11415: crash in processEvent_ Tue, 23 Jun 2015 10:39:41 GMT Thu, 31 Aug 2017 09:58:54 GMT <p> In polygon/details/polygon_arbitrary_formation.hpp, at the end of function processEvent_ (line 1768), I had a case where iter is dereferenced illegally. </p> <p> Changing line 1741 from: </p> <blockquote> <p> if(verticalTail &amp;&amp; !(verticalCount.second)) { </p> </blockquote> <p> to </p> <blockquote> <p> if (verticalTail &amp;&amp; !(verticalCount.second) &amp;&amp; iter != scanData_.end()) { </p> </blockquote> <p> fixes this problem, but it might be the case that this just misses the addition of a new hole. </p> <p> 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: </p> <blockquote> <p> iterator iter = lookUp_(currentY); </p> </blockquote> <blockquote> <p> while(iter != scanData_.end() &amp;&amp; ((iter-&gt;first.pt.x() == x_ &amp;&amp; iter-&gt;first.pt.y() == currentY) or (iter-&gt;first.other_pt.x() == x_ &amp;&amp; iter-&gt;first.other_pt.y() == currentY))) { </p> </blockquote> <blockquote> <blockquote> <p> elementIters.push_back(iter); </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> ... </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> ++iter; </p> </blockquote> </blockquote> <blockquote> <p> } </p> </blockquote> <p> If the original coder assumed that (verticalTail &amp;&amp; !(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. </p> <p> In the seen case, scanData_ contained 3 elements, and elementIters had 2. </p> mhilferink@… https://svn.boost.org/trac10/ticket/11415 https://svn.boost.org/trac10/ticket/11415 Report #10772: boost::geometry::within() does not recognize empty boxes Sat, 08 Nov 2014 19:04:31 GMT Mon, 07 Sep 2015 12:54:36 GMT <p> 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: </p> <ol><li>OGC defines: a.Within(b) ⇔ (a∩b=a) ∧ (I(a)∩E(b)=∅) which holds true. The intersection of an empty box <em>a</em> and a surrounding box <em>b</em> yields <em>a</em>. Since <em>a</em> has no interior, I(a)=∅, thus the second condition is also true. </li><li>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. </li></ol><p> See also the following complete minimal code (it includes also other geometry algorithms that are computed consistently for points and empty boxes): </p> <pre class="wiki">#include &lt;boost/geometry/geometries/point_xy.hpp&gt; #include &lt;boost/geometry/geometries/box.hpp&gt; #include &lt;boost/geometry/algorithms/convert.hpp&gt; #include &lt;boost/geometry/algorithms/within.hpp&gt; #include &lt;boost/geometry/algorithms/covered_by.hpp&gt; #include &lt;boost/geometry/algorithms/intersects.hpp&gt; #include &lt;boost/geometry/algorithms/disjoint.hpp&gt; #include &lt;boost/geometry/algorithms/distance.hpp&gt; // needed for within() -- is this intended? #include &lt;iostream&gt; namespace bg = boost::geometry; typedef bg::model::d2::point_xy&lt;float&gt; Point; typedef bg::model::box&lt;Point&gt; 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 &lt;&lt; " Point Box" &lt;&lt; std::endl; std::cout &lt;&lt; "within: " &lt;&lt; bg::within(point, surrounding) &lt;&lt; " " &lt;&lt; bg::within(pointAsBox, surrounding) &lt;&lt; "\n"; // 1 0 &lt;- std::cout &lt;&lt; "within (self): " &lt;&lt; bg::within(point, point) &lt;&lt; " " &lt;&lt; bg::within(pointAsBox, pointAsBox) &lt;&lt; "\n"; // 1 0 &lt;- std::cout &lt;&lt; "covered_by: " &lt;&lt; bg::covered_by(point, surrounding) &lt;&lt; " " &lt;&lt; bg::covered_by(pointAsBox, surrounding) &lt;&lt; "\n"; // 1 1 std::cout &lt;&lt; "intersects: " &lt;&lt; bg::intersects(point, surrounding) &lt;&lt; " " &lt;&lt; bg::intersects(pointAsBox, surrounding) &lt;&lt; "\n"; // 1 1 std::cout &lt;&lt; "disjoint: " &lt;&lt; bg::disjoint(point, surrounding) &lt;&lt; " " &lt;&lt; bg::disjoint(pointAsBox, surrounding) &lt;&lt; "\n"; // 0 0 std::cout &lt;&lt; std::endl; } </pre><p> The implementation looks as follows (boost/geometry/strategies/cartesian/box_in_box.hpp, line 32): </p> <pre class="wiki">struct box_within_range { template &lt;typename BoxContainedValue, typename BoxContainingValue&gt; static inline bool apply(BoxContainedValue const&amp; bed_min , BoxContainedValue const&amp; bed_max , BoxContainingValue const&amp; bing_min , BoxContainingValue const&amp; bing_max) { return bing_min &lt;= bed_min &amp;&amp; bed_max &lt;= bing_max // contained in containing &amp;&amp; bed_min &lt; bed_max; // interiors overlap } }; </pre><p> The problem is the second line, which uses &lt; 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. </p> <p> 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. </p> bromeon@… https://svn.boost.org/trac10/ticket/10772 https://svn.boost.org/trac10/ticket/10772 Report #11421: [geometry] rstar segmentation fault boost version 1.58.0 Thu, 25 Jun 2015 20:23:15 GMT Mon, 27 Jun 2016 12:47:13 GMT <h2 class="section" id="Notes:">Notes:</h2> <p> 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<sup>4</sup>) of geometry::model::box objects into an geometry::index::rtree object that uses the boost::geometry::index::rstar algorithm, a segmentation fault occurs. </p> <h2 class="section" id="systeminformation:">system information:</h2> <p> gcc (Gentoo 4.8.2 p1.0, pie-0.5.8) 4.8.2<br /> </p> <p> Linux dctest1 3.4.0-gentoo-01 <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/1" title="#1: Bugs: boost.build causes ftjam to segfault (closed: Wont Fix)">#1</a> SMP Sun May 27 15:51:01 CDT 2012 x86_64 Intel(R) Xeon(R) CPU X5675 @ 3.07GHz <a class="missing wiki">GenuineIntel</a> GNU/Linux<br /> </p> <p> <a class="missing wiki">MemTotal</a>: 198094372 kB </p> <h2 class="section" id="testprogramusedtoreproducesegmentationfault:">test program used to reproduce segmentation fault:</h2> <pre class="wiki">// File: test.cpp #include &lt;iostream&gt; #include &lt;boost/geometry.hpp&gt; #include &lt;boost/geometry/index/rtree.hpp&gt; // 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&lt;float&gt;(NUM_BOXES_LAT); const float DELTA_LON_DEG = (MAX_LON_DEG - MIN_LON_DEG)/static_cast&lt;float&gt;(NUM_BOXES_LON); using COORD_TYPE = boost::geometry::cs::cartesian; using Point = boost::geometry::model::point&lt;float, 2, COORD_TYPE&gt;; using Box = boost::geometry::model::box&lt;Point&gt;; using BoxIDPair = std::pair&lt;Box, unsigned&gt;; 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&lt; BoxIDPair, boost::geometry::index::rstar&lt;16, 4&gt; &gt; locationGeometryTable; // seg fault @ 10^4 boxes boost::geometry::index::rtree&lt; BoxIDPair, boost::geometry::index::rstar&lt;16&gt; &gt; locationGeometryTable; // seg fault @ 10^4 boxes // boost::geometry::index::rtree&lt; BoxIDPair, boost::geometry::index::quadratic&lt;16&gt; &gt; locationGeometryTable; // pass @ 10^4 boxes; pass @ 10^6 for(unsigned idxLat=0; idxLat&lt;NUM_BOXES_LAT; ++idxLat) { float lat = idxLat*DELTA_LAT_DEG + MIN_LAT_DEG; for(unsigned idxLon=0; idxLon&lt;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; } </pre><h2 class="section" id="build:">build:</h2> <p> $ gcc -std=c++11 -lstdc++ -I$BOOST_ROOT/include -DBUFFERSIZE=4096 -g -O0 test.cpp -o test </p> <h2 class="section" id="run:">run:</h2> <p> $ ./test<br /> Segmentation fault </p> <h2 class="section" id="debug:">debug:</h2> <pre class="wiki">$ 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 &lt;http://gnu.org/licenses/gpl.html&gt; 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: &lt;http://bugs.gentoo.org/&gt;... 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&lt;boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;*, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;*&gt; (first=0x7fffffffc188, last=0x7fffffffc1b8, dst=0x406a6a &lt;boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;::apply_visitor&lt;boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::---Type &lt;return&gt; to continue, or q &lt;return&gt; to quit--- index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt; &gt;(boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt;&amp;)+62&gt;) 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&lt;boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;*, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;*&gt; ( first=0x7fffffffc188, last=0x7fffffffc1b8, dst=0x406a6a &lt;boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost---Type &lt;return&gt; to continue, or q &lt;return&gt; to quit--- ::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;::apply_visitor&lt;boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt; &gt;(boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt;&amp;)+62&gt;) 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&lt;boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_interna---Type &lt;return&gt; to continue, or q &lt;return&gt; to quit--- l_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, 17ul&gt;::assign_dispatch&lt;boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;*&gt; ( this=0x406a62 &lt;boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;::apply_visitor&lt;boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt; &gt;(boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allo---Type &lt;return&gt; to continue, or q &lt;return&gt; to quit--- cator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt;&amp;)+54&gt;, 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&lt;boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, 17ul&gt;::assign&lt;boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;*&gt; ( this=0x406a62 &lt;boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, 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 &lt;return&gt; to continue, or q &lt;return&gt; to quit--- t::detail::variant::void_&gt;::apply_visitor&lt;boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt; &gt;(boost::geometry::index::detail::rtree::visitors::rstar::level_insert&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt;&amp;)+54&gt;, 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&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::rstar_tag&gt;::apply&lt;boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt; (n=..., second_node=..., box1=..., box2=..., parameters=..., translator=..., allocators=...) ---Type &lt;return&gt; to continue, or q &lt;return&gt; 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&lt;1ul, boost::geometry::index::detail::rtree::ptr_pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::variant&lt;boost::geometry::index::detail::rtree::variant_leaf&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::variant_internal_node&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt;, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_&gt;*&gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::detail::rtree::options&lt;boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, 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&gt;, boost::geometry::index::detail::translator&lt;boost::geometry::index::indexable&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, boost::geometry::index::equal_to&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt; &gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::allocators&lt;std::allocator&lt;std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt; &gt;, std::pair&lt;boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, unsigned int&gt;, boost::geometry::index::rstar&lt;16ul, 4ul, 4ul, 32ul&gt;, boost::geometry::model::box&lt;boost::geometry::model::point&lt;float, 2ul, boost::geometry::cs::cartesian&gt; &gt;, boost::geometry::index::detail::rtree::node_variant_static_tag&gt; &gt;::operator() ( this=&lt;error reading variable: Cannot access memory at address 0x18&gt;, n=&lt;error reading variable: Cannot access memory at address 0x10&gt;) 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?) </pre> Celair <mathom.house@…> https://svn.boost.org/trac10/ticket/11421 https://svn.boost.org/trac10/ticket/11421 Report #5638: greg_month::get_month_map_ptr is not thread safe Fri, 24 Jun 2011 08:06:03 GMT Tue, 17 Mar 2015 16:16:58 GMT <p> We recently have found a crash issue related to this function in greg_month.cpp. </p> <p> 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. </p> fatbone <fatbone@…> https://svn.boost.org/trac10/ticket/5638 https://svn.boost.org/trac10/ticket/5638 Report #605: Support different DST rules in timezone db based on years Mon, 17 Apr 2006 13:20:56 GMT Sun, 28 Nov 2010 06:27:44 GMT <pre class="wiki">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. </pre> nobody https://svn.boost.org/trac10/ticket/605 https://svn.boost.org/trac10/ticket/605 Report #889: Insane Dependencies Mon, 09 Apr 2007 23:07:09 GMT Sun, 22 Nov 2009 20:03:13 GMT <pre class="wiki">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. :) </pre> nobody https://svn.boost.org/trac10/ticket/889 https://svn.boost.org/trac10/ticket/889 Report #1207: Method "from_julian_day_number" (class gregorian_calendar) not documented Thu, 23 Aug 2007 10:19:03 GMT Sun, 01 Jul 2012 17:53:56 GMT <p> please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ? library: date_time </p> <p> thanks </p> <p> gizmo </p> thom_schu@… https://svn.boost.org/trac10/ticket/1207 https://svn.boost.org/trac10/ticket/1207 Report #3132: Provide conversions to time_t Thu, 04 Jun 2009 09:23:12 GMT Sun, 01 Jul 2012 18:11:19 GMT <p> Extracted from <a class="assigned ticket" href="https://svn.boost.org/trac10/ticket/889" title="#889: Feature Requests: Insane Dependencies (assigned)">#889</a>. </p> <p> ==========8&lt;============ Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :) ==========&gt;8============ </p> <p> Need to provide conversion function from Boost.<a class="missing wiki">DateTime</a> types to std::time_t. </p> Andrey Semashev https://svn.boost.org/trac10/ticket/3132 https://svn.boost.org/trac10/ticket/3132 Report #8183: boost::geometry::intersection on two polygons returns incorrect empty intersection Tue, 26 Feb 2013 09:24:56 GMT Sun, 17 Mar 2013 17:47:02 GMT <p> Hi </p> <p> 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? </p> <p> Thanks </p> <p> Matthew Danielsen </p> <pre class="wiki"> 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&lt; boost::geometry::model::polygon&lt;boost::geometry::model::d2::point_xy&lt;T&gt; &gt; &gt; intersectionPolygons; boost::geometry::intersection(triangle2D, box2D, intersectionPolygons); assert(intersectionPolygons.size() != 0); // Assert fails </pre> matthewd@… https://svn.boost.org/trac10/ticket/8183 https://svn.boost.org/trac10/ticket/8183 Report #8366: "Overlay invalid input exception" (3) Tue, 02 Apr 2013 08:19:24 GMT Wed, 19 Nov 2014 15:14:58 GMT <p> 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. </p> <p> As always, my polygon type is oriented <strong>counter-clockwise</strong> and <strong>not closed</strong>, my point type is based on <strong>int</strong>. </p> <p> This is the data that triggers the exception: </p> <pre class="wiki">_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; } </pre><p> This is my code that wraps boost::geometry to implement the operators used above: </p> <pre class="wiki">template&lt;typename T&gt; template&lt;typename Geometry&gt; _TPolygon&lt; T &gt; _TPolygon&lt; T &gt;::operator-(Geometry const&amp; geometry) const { // should not be necessary //if( boost::geometry::area(geometry)==0 ) return *this; _TPolygon&lt; T &gt; polygonOut; boost::geometry::difference(*this, geometry, polygonOut); // should not be necessary //boost::geometry::correct( polygonOut ); return polygonOut; } template&lt;typename T&gt; template&lt;typename Geometry&gt; _TPolygon&lt;T&gt;&amp; _TPolygon&lt; T &gt;::operator-=(Geometry const&amp; geometry) { // boost::geometry::difference cannot operate in-place // http://lists.boost.org/geometry/2012/02/1796.php *this = *this - geometry; return *this; } template&lt;typename T&gt; template&lt;typename Geometry&gt; _TPolygon&lt; T &gt; _TPolygon&lt; T &gt;::operator^(Geometry const&amp; geometry) const { _TPolygon&lt; T &gt; polygonOut; boost::geometry::sym_difference(*this, geometry, polygonOut); // should not be necessary //boost::geometry::correct( polygonOut ); return polygonOut; } </pre> Volker Schöch <vschoech@…> https://svn.boost.org/trac10/ticket/8366 https://svn.boost.org/trac10/ticket/8366 Report #8701: wrong empty polygon-linestring intersection with overlapping edges Sun, 16 Jun 2013 09:21:11 GMT Tue, 27 Aug 2013 21:04:08 GMT <p> The returned intersection between these geometries is empty, although they overlap completely and I would expect the full linestring to be returned: </p> <blockquote> <p> 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) </p> </blockquote> <p> If I move one of them slightly, I get a correct intersection instead of an empty set. I'm using double for point coordinates. </p> <p> This issue might be related to <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/8310" title="#8310: Bugs: Wrong results with overlapping polygons (closed: fixed)">#8310</a> and <a class="assigned ticket" href="https://svn.boost.org/trac10/ticket/8183" title="#8183: Bugs: boost::geometry::intersection on two polygons returns incorrect empty ... (assigned)">#8183</a>. </p> aar@… https://svn.boost.org/trac10/ticket/8701 https://svn.boost.org/trac10/ticket/8701 Report #11580: invalid buffer result Tue, 25 Aug 2015 10:00:19 GMT Sat, 26 Mar 2016 15:33:14 GMT <p> 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. </p> <pre class="wiki"> #include &lt;boost/geometry.hpp&gt; #include &lt;boost/geometry/geometries/geometries.hpp&gt; namespace bg = boost::geometry; int main() { typedef bg::model::point&lt;double, 2, bg::cs::cartesian&gt; point; typedef bg::model::polygon&lt;point&gt; 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&lt;double&gt; 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&lt;Polygon&gt; grown; bg::buffer(poly, grown, distance_strategy, side_strategy, join_strategy, end_strategy, point_strategy); std::cout &lt;&lt; bg::wkt(grown) &lt;&lt; std::endl; return 0; } </pre><p> The returned shape is: </p> <p> 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))) </p> Marios Visvardis <visvardis.marios@…> https://svn.boost.org/trac10/ticket/11580 https://svn.boost.org/trac10/ticket/11580 Report #12125: Another problems performing boolean operations on polygons with shared edges Wed, 13 Apr 2016 22:43:43 GMT Fri, 28 Oct 2016 16:17:05 GMT <p> Trying to solve problems with union_ operation on mpolygons with shared edges (<a class="ext-link" href="https://svn.boost.org/trac/boost/ticket/12118"><span class="icon">​</span>https://svn.boost.org/trac/boost/ticket/12118</a>) with help of boost 1.61.0 beta. But instead of getting problems with zero areas, I'm getting really wrong result. </p> <p> For example </p> <p> 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))) </p> <p> 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))) </p> <p> 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))) </p> ev.mipt@… https://svn.boost.org/trac10/ticket/12125 https://svn.boost.org/trac10/ticket/12125 Report #13072: boost::geometry::intersection different results for CCW and CW Wed, 14 Jun 2017 10:57:24 GMT Wed, 14 Jun 2017 13:13:25 GMT <p> Hello,<br /> </p> <p> when calculating the intersection between these two polygons the results differ dependent on the orientation (CW vs CCW). </p> <pre class="wiki"> #include &lt;boost/geometry/geometry.hpp&gt; #include &lt;boost/geometry/geometries/polygon.hpp&gt; #include &lt;boost/geometry/geometries/point_xy.hpp&gt; int main(int argc, char* argv[]) { typedef boost::geometry::model::polygon&lt;boost::geometry::model::d2::point_xy&lt;double&gt;, true, false &gt; boost_polygon_CW_Open; typedef boost::geometry::model::polygon&lt;boost::geometry::model::d2::point_xy&lt;double&gt;, false, false &gt; 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&lt;boost_polygon_CW_Open&gt; 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&lt;boost_polygon_CCW_Open&gt; output_ccw; boost::geometry::intersection(p1_ccw_open, p2_ccw_open, output_ccw); // incorrect: output_cw is empty!!! return 0; } </pre> kle@… https://svn.boost.org/trac10/ticket/13072 https://svn.boost.org/trac10/ticket/13072 Report #13444: boost::geometry::buffer returns only partial result (regression over 1.63.0) Fri, 09 Feb 2018 10:44:56 GMT Sat, 17 Feb 2018 17:53:03 GMT <p> using boost::geometry::buffer with multilinestring, only 1 of expected 3 polygons are returned. </p> <p> The fix ist to buffer each linestring separately and union_ them into one multipolygon. This also turned out to be much faster. </p> <p> I do not have a simple example, but a rather complex one, which I will attach. </p> <p> Version 1.63.0 returned all 3 polygons, but was also rather slow when compared with the workaround. </p> andre.meyer@… https://svn.boost.org/trac10/ticket/13444 https://svn.boost.org/trac10/ticket/13444 Report #13522: Invalid empty result using boost::geometry::difference Mon, 16 Apr 2018 09:43:01 GMT Wed, 16 May 2018 06:21:58 GMT <p> Hello, </p> <p> 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. </p> <p> Code to reproduce this: </p> <p> using point_type = boost::geometry::model::d2::point_xy&lt;double&gt;; using polygon = boost::geometry::model::polygon&lt;point_type&gt;; using multi_polygon = boost::geometry::model::multi_polygon&lt;polygon&gt;; </p> <blockquote> <p> BoostGeometryBridge::Polygon2d_t Right<a class="changeset" href="https://svn.boost.org/trac10/changeset/3" title="Tweak disclaimer text">[3]</a>; BoostGeometryBridge::MultiPolygon2d_t Left<a class="changeset" href="https://svn.boost.org/trac10/changeset/4" title="Tweak disclaimer formatting, again">[4]</a>; </p> </blockquote> <blockquote> <p> 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<a class="missing changeset" title="No changeset 0 in the repository">[0]</a>); </p> </blockquote> <blockquote> <p> 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<a class="missing changeset" title="No changeset 0 in the repository">[0]</a>); boost::geometry::read_wkt("POLYGON((2.74708725756255001 5.64524915118547987, 1.48149582377297007 4.63517624723808019, 2.7471454369183701 4.6352491528611397, 2.74708725756255001 5.64524915118547987))", Right<a class="changeset" href="https://svn.boost.org/trac10/changeset/1" title="Import core sources for SVNmanger 0.38 ">[1]</a>); 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<a class="changeset" href="https://svn.boost.org/trac10/changeset/2" title="Add Boost Disclaimer">[2]</a>); </p> </blockquote> <blockquote> <p> for(int i = 0; i &lt; 3; i++) { </p> <blockquote> <p> boost::geometry::difference(Left[i], Right[i], Left[i + 1]); </p> </blockquote> <p> } </p> </blockquote> <p> Final result in Left<a class="changeset" href="https://svn.boost.org/trac10/changeset/3" title="Tweak disclaimer text">[3]</a> is empty. </p> lehnert@… https://svn.boost.org/trac10/ticket/13522 https://svn.boost.org/trac10/ticket/13522 Report #13553: intersection gives wrong result Mon, 30 Apr 2018 14:04:02 GMT Wed, 16 May 2018 06:21:26 GMT <p> The following polygons result in a wrong intersection: </p> <p> using point_type = boost::geometry::model::d2::point_xy&lt;double&gt;; typedef boost::geometry::model::ring&lt;point_type, false, true&gt; polygon; </p> <p> polygon op1, op2; </p> <p> 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&lt;polygon&gt; result; boost::geometry::intersection(op1, op2, result); </p> <p> result is equal to op1, while op1 is mostly outside op2. </p> marnix.berg@… https://svn.boost.org/trac10/ticket/13553 https://svn.boost.org/trac10/ticket/13553 Report #5734: possible handle leak in posix implementation copy_file_api Tue, 26 Jul 2011 04:04:07 GMT Tue, 26 Jul 2011 14:49:21 GMT <p> There is possible handle leak in POSIX implementation of function <strong>copy_file_api</strong>. </p> <pre class="wiki">... if ((infile = ::open(from_p.c_str(), O_RDONLY))&lt; 0) { return false; } struct stat from_stat; if (::stat(from_p.c_str(), &amp;from_stat)!= 0) { return false; } ... </pre><p> if <strong>::stat</strong> failed, then function exits without closing <strong>infile</strong> handle. </p> <p> This problem exists both in <strong>v3</strong> and <strong>v2</strong> implementations of filesystem. Also this problem exists in previous releases. </p> alexey.kutumov@… https://svn.boost.org/trac10/ticket/5734 https://svn.boost.org/trac10/ticket/5734 Report #5850: last_write_time on Windows may not work on SMB2-network-mounted drive Wed, 31 Aug 2011 15:22:13 GMT Tue, 11 Oct 2011 12:21:05 GMT <p> Consider the following logical operation against a file on a network-mounted drive served over SMB2: </p> <ol><li>fopen("r+b")/fwrite/fclose a file. </li><li>boost::filesystem::last_write_time(file, some other specific time) </li><li>fopen("rb")/fclose a file. </li></ol><p> 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. </p> <p> I believe this is happening because boost's non-POSIX/Windows implementation of last_write_time uses <a class="missing wiki">CreateFile</a>() and asks only for FILE_WRITE_ATTRIBUTES. Using GENERIC_WRITE appears to work correctly. </p> <p> Also note, calling utime() instead of boost::filesystem::last_write_time() works correctly. </p> <p> Please see attached test code demonstrating boost's failure, utime()'s success, and native API workaround. </p> <p> Please feel free to contact me for follow up. Thanks, -Ken </p> Ken Harris <kharris@…> https://svn.boost.org/trac10/ticket/5850 https://svn.boost.org/trac10/ticket/5850 Report #5937: Sun C++ 5.11 Linux compilation errors: operations.cpp Sat, 24 Sep 2011 12:46:46 GMT Tue, 27 Sep 2011 17:59:30 GMT <p> CC: Sun C++ 5.11 Linux_i386 2010/08/13 usage: CC [ options ] files. Use 'CC -flags' for details </p> <p> "libs/filesystem/v3/src/operations.cpp", line 1760: Error: DT_UNKNOWN is not defined. </p> <p> "libs/filesystem/v3/src/operations.cpp", line 1766: Error: DT_DIR is not defined. </p> <p> "libs/filesystem/v3/src/operations.cpp", line 1768: Error: DT_REG is not defined. </p> <p> "libs/filesystem/v3/src/operations.cpp", line 1770: Error: DT_LNK is not defined. </p> <p> 4 Error(s) detected. </p> <blockquote> <p> "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" </p> </blockquote> Peter Loibl <boost@…> https://svn.boost.org/trac10/ticket/5937 https://svn.boost.org/trac10/ticket/5937 Report #6188: boost directory_iterator construct throw segmentation fault Thu, 01 Dec 2011 04:13:41 GMT Sun, 22 Jan 2012 15:50:02 GMT <p> Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory. </p> anonymous https://svn.boost.org/trac10/ticket/6188 https://svn.boost.org/trac10/ticket/6188 Report #6638: convert_aux fails while intializing global variable Wed, 29 Feb 2012 22:39:27 GMT Wed, 26 Apr 2017 16:12:09 GMT <p> <em>path_traits.cpp</em><br /> </p> <p> <strong>convert_aux</strong> fails in global scope:<br /> </p> <p> Trying to initialize global path variable by concatenating '/' a wide string path w/ narrow string path fails! <br /> </p> <p> "Unhandled exception at 0x0f8bc688 (msvcp100d.dll) in paths.exe: 0xC0000005: Access violation reading location 0x00000000." <br /> </p> <p> 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 /> </p> <p> Additional info: WIN 32 and 64 bit, MSVS2010<br /> </p> <pre class="wiki">#include &lt;iostream&gt; #include &lt;boost/filesystem.hpp&gt; 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 &lt;&lt; r.string() &lt;&lt; std::endl; return 0; } </pre><p> <br /> </p> <p> P.S. If more info is required I will reply here not by email. </p> john doe <johndoe> https://svn.boost.org/trac10/ticket/6638 https://svn.boost.org/trac10/ticket/6638 Report #8388: windows_file_codecvt should be allocated with _NEW_CRT Thu, 04 Apr 2013 10:08:14 GMT Sat, 02 Aug 2014 16:16:04 GMT <p> 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. </p> pedro.larroy@… https://svn.boost.org/trac10/ticket/8388 https://svn.boost.org/trac10/ticket/8388 Report #8642: Global locale prevents from using Boost.Filesystem in global constructors and destructors Mon, 03 Jun 2013 13:06:50 GMT Tue, 07 Mar 2017 09:17:41 GMT <p> 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. </p> <p> 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. </p> Andrey Semashev https://svn.boost.org/trac10/ticket/8642 https://svn.boost.org/trac10/ticket/8642 Report #9816: boost::filesystem::is_empty does not work for symbolic links on Windows Sun, 30 Mar 2014 10:11:13 GMT Thu, 10 Sep 2015 13:04:38 GMT <p> Hi, </p> <p> 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. </p> <p> 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. </p> <p> I at first asked at Stackoverflow for some help: <a class="ext-link" href="http://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks"><span class="icon">​</span>Boost::filesystem::is_empty() returns false for Symlinks</a> </p> <p> I also created a Github project which reproduces the problem: <a class="ext-link" href="https://github.com/monsdar/BoostSymLinkError"><span class="icon">​</span>Github - BoostSymLinkError</a> </p> Nils Brinkmann <monsdar+boost@…> https://svn.boost.org/trac10/ticket/9816 https://svn.boost.org/trac10/ticket/9816 Report #9824: boost::filesystem::is_empty() doesn't work with symlinks on Windows Tue, 01 Apr 2014 09:17:13 GMT Thu, 10 Sep 2015 13:03:43 GMT <p> See the original information on this problem in this Stackoverflow question: </p> <blockquote> <p> hxxp://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks </p> </blockquote> <p> The person who reported that problem/asked the question on Stackoverflow also set up a github project that demonstrates the problem: </p> <blockquote> <p> hxxps://github.com/monsdar/BoostSymLinkError </p> </blockquote> <p> Basically, the <code>filesystem::is_empty()</code> function doesn't follow a symlink, so it will return false even if the target of the symlink has a length greater than 0. </p> <p> The V2 filesystem library worked for this situation. The difference is that V2 used the <code>stat()</code> function in the VC++ library, while the V3 filesystem library uses the Win32 <code>GetFileAttributesExW()</code> API. The latter does not follow symlinks and returns a file size of 0 regardless of the size of the symlink target. </p> <p> Attached is a diff for libs/filesystem/src/operations.cpp which uses the <code>stat()</code> technique very similar to what was used in filesystem V2. A few differences: </p> <ul><li><code>_wstat()</code> is used instead of <code>stat()</code> to accommodate UNICODE filenames </li><li>a bit test using <code>_S_IFDIR</code> is used to determine if the path is a directory instead of <code>S_ISDIR()</code> because the VC++ library doesn't include a <code>S_ISDIR()</code> or <code>_S_ISDIR()</code> macro. </li></ul><p> 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 <code>GetFileAttributesExW()</code> API in filesystem V3 were, so I'm not sure if there's a fundamental flaw in using <code>_wstat()</code> that would prevent using it in V3. </p> michael.burr@… https://svn.boost.org/trac10/ticket/9824 https://svn.boost.org/trac10/ticket/9824 Report #10205: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid Wed, 16 Jul 2014 11:59:58 GMT Wed, 29 Oct 2014 15:18:26 GMT <p> Ok this is still broken (see Ticket <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/5928" title="#5928: Bugs: FileSystem runtime error: locale::facet::_S_create_c_locale name not valid (closed: fixed)">#5928</a>). On Solaris 10 (sparc) compile this... </p> <p> #include &lt;iostream&gt; #include &lt;boost/filesystem.hpp&gt; </p> <p> int main (void) { </p> <blockquote> <p> std::cout &lt;&lt; boost::filesystem::unique_path("/some/random/path/%%%%%%%").c_str() &lt;&lt; std::endl; return 0; </p> </blockquote> <p> } </p> <p> linking against system and filesystem </p> <p> 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.. </p> <p> g++ test.cpp -I../../ -L. -lboost_filesystem -lboost_system </p> <p> Below are the results... </p> <p> 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' </p> <blockquote> <p> what(): locale::facet::_S_create_c_locale name not valid </p> </blockquote> <p> Abort (core dumped) -bash-3.2$ LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' </p> <blockquote> <p> what(): locale::facet::_S_create_c_locale name not valid </p> </blockquote> <p> 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' </p> <blockquote> <p> what(): locale::facet::_S_create_c_locale name not valid </p> </blockquote> <p> Abort (core dumped) -bash-3.2$ LC_ALL=C LD_LIBRARY_PATH=. ./a.out /some/random/path/7fff459 </p> <p> This is utterly crippling and renders boost filesystem useless on Solaris 10. </p> sleary@… https://svn.boost.org/trac10/ticket/10205 https://svn.boost.org/trac10/ticket/10205 Report #10233: create_directories causes invalid read Wed, 23 Jul 2014 13:48:27 GMT Fri, 01 Dec 2017 07:07:32 GMT <p> The following code, when run under Valgrind, will report two instances of invalid reads during program close (after main). </p> <p> Tested on Ubuntu Linux x64 12.04 (kernel 3.8.0) with gcc 4.6.3. </p> <pre class="wiki">#include &lt;stdlib.h&gt; #include &lt;boost/filesystem.hpp&gt; int main() { system("rm -rf /tmp/test"); // make sure directory doesn't already exist boost::filesystem::create_directories("/tmp/test"); return 0; } </pre> Itay C <itay.chamiel@…> https://svn.boost.org/trac10/ticket/10233 https://svn.boost.org/trac10/ticket/10233 Report #10485: heap-use-after-free using C++11 range loop Tue, 09 Sep 2014 16:14:17 GMT Sun, 26 Oct 2014 15:35:40 GMT <p> Repro code: </p> <pre class="wiki">#include &lt;stdio.h&gt; #include &lt;boost/filesystem.hpp&gt; int main() { boost::filesystem::path dir("/"); for (char c : dir.filename().string()) printf("%c\n", c); } </pre><p> 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: </p> <pre class="wiki">================================================================= ==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 =&gt;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 </pre> iamvfx@… https://svn.boost.org/trac10/ticket/10485 https://svn.boost.org/trac10/ticket/10485 Report #10900: read_symlink fails to correctly read NTFS junctions Fri, 26 Dec 2014 16:16:26 GMT Fri, 22 Sep 2017 08:59:32 GMT <p> <em>Tested on Windows 7 64-bit.</em> </p> <p> NTFS directory junctions are now recognized as a symlink by <code>is_reparse_point_a_symlink</code> but <code>read_symlink</code> does not correctly handle those "mount point" reparse points yet. </p> <p> Among other things this also breaks the <code>canonical</code> operation. </p> <p> The <code>REPARSE_DATA_BUFFER</code> returned by <code>DeviceIoControl</code> needs to be accessed differently for regular symlinks and mount points. See msdn.microsoft.com/en-us/library/ff552012.aspx </p> <p> Accessing the "PrintName" as a symlink typically results in the first two (wide) characters of the path being skipped and generally in undefined behavior. </p> <p> A possible fix would be to add a conditional statement checking <code>info.rdb.ReparseTag == IO_REPARSE_TAG_MOUNT_POINT</code> and then amend the <code>symlink_path.assign</code> call accordingly (using <code>info.rdb.MountPointReparseBuffer</code> instead of <code>info.rdb.SymbolicLinkReparseBuffer</code>). </p> <p> In version 1.57.0 the offending code can be found in <em>libs/filesystem/src/operations.cpp</em> around line 1514. </p> Benjamin Kummer-Hardt <benjamin@…> https://svn.boost.org/trac10/ticket/10900 https://svn.boost.org/trac10/ticket/10900 Report #2150: Inspect needs to check for missing files Mon, 28 Jul 2008 14:51:59 GMT Thu, 03 Jan 2013 19:10:48 GMT <p> Objective: Report missing files early enough to take corrective action before a crisis develops. Include generated doc files in the lists searched for. </p> <p> 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. </p> <p> See attached file for possible "required_files.txt" format. </p> Beman Dawes https://svn.boost.org/trac10/ticket/2150 https://svn.boost.org/trac10/ticket/2150 Report #3965: missing functions last_access_time() and last_status_change_time() Sun, 28 Feb 2010 05:35:24 GMT Fri, 20 Apr 2012 13:03:10 GMT <p> In Boost.Filesystem I can find a function: </p> <p> template &lt;class Path&gt; std::time_t last_write_time(const Path&amp; p); </p> <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? </p> <p> template &lt;class Path&gt; std::time_t last_access_time(const Path&amp; p); template &lt;class Path&gt; std::time_t last_status_change_time(const Path&amp; p); </p> <p> Cheers, Sascha </p> Sascha Ochsenknecht https://svn.boost.org/trac10/ticket/3965 https://svn.boost.org/trac10/ticket/3965 Report #4494: recursive_directory_iterator throws unexpectedly in the non-throw mode Fri, 30 Jul 2010 06:13:15 GMT Sat, 31 Aug 2013 15:54:02 GMT <p> 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: </p> <blockquote> <p> boost::system::error_code m_ec; for ( recursive_directory_iterator itr(root, m_ec), end_itr; itr != end_itr; ++itr) </p> </blockquote> <p> 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: </p> <blockquote> <p> void increment() { </p> <blockquote> <p> BOOST_ASSERT(m_imp.get() &amp;&amp; "increment of end recursive_directory_iterator"); m_imp-&gt;increment(0); if (m_imp-&gt;m_stack.empty()) m_imp.reset(); <em> done, so make end iterator </em></p> </blockquote> </blockquote> <p> } </p> <p> Where m_imp is an object of recur_dir_itr_imp: </p> <blockquote> <p> void recur_dir_itr_imp::increment(system::error_code* ec) <em> ec == 0 means throw on error </em></p> </blockquote> <p> { … } </p> <p> 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. </p> ttan@… https://svn.boost.org/trac10/ticket/4494 https://svn.boost.org/trac10/ticket/4494 Report #5896: Range directory iterators Tue, 13 Sep 2011 22:42:39 GMT Thu, 19 Apr 2012 15:26:00 GMT <p> 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. </p> <p> Basically, it could just be a couple of helper functions that create a boost::iterator_range&lt;bfs::directory_iterator&gt; instance. </p> jmckesson@… https://svn.boost.org/trac10/ticket/5896 https://svn.boost.org/trac10/ticket/5896 Report #6018: Add touch() and create_file() functions Thu, 13 Oct 2011 12:38:26 GMT Thu, 13 Oct 2011 12:38:51 GMT <p> 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. </p> <p> 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. </p> <p> Alternatively, both could return a bool, true if successful, and not consider it an error if the file, respectfully, already/doesn't exist. </p> Beman Dawes https://svn.boost.org/trac10/ticket/6018 https://svn.boost.org/trac10/ticket/6018 Report #6521: Directory listing using C++11 range-based for loops Sat, 04 Feb 2012 18:15:21 GMT Tue, 13 Jun 2017 14:11:26 GMT <p> I have written a simple 'container' class for a directory, 'containing' all of its subdirectories: </p> <pre class="wiki">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(); } }; } } </pre><p> so that that range-based for loop can be used: </p> <pre class="wiki">for(auto i:directory("/home")){ ... } </pre> mustrumr97@… https://svn.boost.org/trac10/ticket/6521 https://svn.boost.org/trac10/ticket/6521 Report #10078: Incomplete API with respect to file related dates (cration, modification, access) Thu, 29 May 2014 09:38:36 GMT Thu, 29 May 2014 12:27:29 GMT <p> The following features are missing: </p> <ul><li>read file's creation date </li><li>read file's last access date </li><li>read file's creation date with a precision higher than seconds </li><li>read file's last access date with a precision higher than seconds </li><li>read file's last access date with a precision higher than seconds </li><li>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) </li></ul><p> Possible implementation notes: </p> <ul><li>How to get high precision file date on Linux </li></ul><p> <a class="ext-link" href="http://stackoverflow.com/questions/13382695/how-to-get-last-modification-time-of-a-file-with-epoch-time-format-precision-mi"><span class="icon">​</span>http://stackoverflow.com/questions/13382695/how-to-get-last-modification-time-of-a-file-with-epoch-time-format-precision-mi</a> </p> <ul><li>How to get high precision file date on Windows </li></ul><p> <a class="ext-link" href="http://msdn.microsoft.com/en-us/library/aa364946.aspx"><span class="icon">​</span>http://msdn.microsoft.com/en-us/library/aa364946.aspx</a> </p> <p> Example of current use of this feature in existing applications: </p> <p> ls --full-time </p> David Lastovicka <david@…> https://svn.boost.org/trac10/ticket/10078 https://svn.boost.org/trac10/ticket/10078 Report #11663: No way to query file extension without allocating memory Thu, 17 Sep 2015 06:44:37 GMT Fri, 09 Sep 2016 18:14:22 GMT <p> 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. </p> <p> That means that for solutions implementing search-by-extension such as is written in: </p> <p> <a class="ext-link" href="http://stackoverflow.com/questions/11140483/how-to-get-list-of-files-with-a-specific-extension-in-a-given-folder"><span class="icon">​</span>http://stackoverflow.com/questions/11140483/how-to-get-list-of-files-with-a-specific-extension-in-a-given-folder</a> </p> <p> there could be hundreds of memory allocations for just iterating a directory structure. IMO, there really shouldn't be. </p> <p> I propose adding the function bool path::has_extension(string const&amp;) which can compare the extension in a memory-friendly way. </p> matthew.chaplain@… https://svn.boost.org/trac10/ticket/11663 https://svn.boost.org/trac10/ticket/11663 Report #2066: Inspect needs to review generated doc files too Thu, 03 Jul 2008 11:16:35 GMT Thu, 03 Jan 2013 19:11:23 GMT <p> Inspect needs to run on release snapshot so that it is looking at the generated doc files too. </p> <p> 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. </p> <p> 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. </p> Beman Dawes https://svn.boost.org/trac10/ticket/2066 https://svn.boost.org/trac10/ticket/2066 Report #5745: Use native typeof support for Oracle Solaris Studio C++ compiler Mon, 01 Aug 2011 14:51:58 GMT Tue, 09 Aug 2011 09:50:47 GMT <p> 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. </p> <p> Here is proposed patch: </p> <pre class="wiki">*** 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 &lt; 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 </pre> Maxim Kartashev <maxim.kartashev@…> https://svn.boost.org/trac10/ticket/5745 https://svn.boost.org/trac10/ticket/5745 Report #2875: Windows: ip::tcp::acceptor::local_endpoint() cannot be used in socket connect Fri, 20 Mar 2009 06:19:50 GMT Thu, 09 Apr 2009 13:05:18 GMT <p> 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. </p> <p> 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. </p> Benjamin Carlyle <ben.carlyle@…> https://svn.boost.org/trac10/ticket/2875 https://svn.boost.org/trac10/ticket/2875 Report #9991: WConversion issue in json_parser_write.hpp Fri, 02 May 2014 06:21:11 GMT Wed, 10 Feb 2016 13:04:37 GMT <p> File Name: 1_54_0/boost/property_tree/detail/json_parser_write.hpp </p> <p> There is a severe problem with the -Wconversion issue in the json_parser_write.hpp </p> <p> Problematic code: </p> <blockquote> <p> else </p> <blockquote> <p> { </p> <blockquote> <p> const char *hexdigits = "0123456789ABCDEF"; typedef typename make_unsigned&lt;Ch&gt;::type UCh; unsigned long u = (std::min)(static_cast&lt;unsigned long&gt;( </p> <blockquote> <p> static_cast&lt;UCh&gt;(*b)), </p> </blockquote> <p> 0xFFFFul); </p> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> <strong> int d1 = u / 4096; u -= d1 * 4096; </strong></p> <blockquote> <p> int d2 = u / 256; u -= d2 * 256; int d3 = u / 16; u -= d3 * 16; int d4 = u;<strong> </strong></p> </blockquote> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <blockquote> <p> result += Ch('<br />'); result += Ch('u'); result += Ch(hexdigits[d1]); result += Ch(hexdigits[d2]); result += Ch(hexdigits[d3]); result += Ch(hexdigits[d4]); </p> </blockquote> </blockquote> <p> } </p> </blockquote> </blockquote> <p> 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. </p> <p> the above need to be fixed. </p> abhi.california@… https://svn.boost.org/trac10/ticket/9991 https://svn.boost.org/trac10/ticket/9991 Report #10188: Loses floating point precision on round trip Thu, 10 Jul 2014 13:54:12 GMT Fri, 23 Jan 2015 12:25:23 GMT <p> ptrees stream_translator uses a precision of std::numeric_limits&lt;F&gt;::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 <a class="reopened ticket" href="https://svn.boost.org/trac10/ticket/9177" title="#9177: Bugs: Improved serialization of floating point values (reopened)">ticket:9177</a> for a similar issue. </p> <p> The attached test produces the following output pre-patch: </p> <pre class="wiki">in : -1.8312345000098765e-08 out: -1.8312345000098762e-08 Wrong </pre><p> and after patch: </p> <pre class="wiki">in : -1.8312345000098765e-08 out: -1.8312345000098765e-08 Right </pre> Magne OEstlyngen <magne+boost@…> https://svn.boost.org/trac10/ticket/10188 https://svn.boost.org/trac10/ticket/10188 Report #11502: narrow_encoding: -Wtype-limits warning is reported Sun, 26 Jul 2015 12:28:26 GMT Wed, 10 Feb 2016 12:51:31 GMT <p> -Wtype-limit is reported on this assert: </p> <blockquote> <p> char to_internal_trivial(char c) const { </p> <blockquote> <p> assert(c &lt;= 0x7f); &lt;=== Type limit return c; </p> </blockquote> <p> } </p> </blockquote> davido https://svn.boost.org/trac10/ticket/11502 https://svn.boost.org/trac10/ticket/11502 Report #5658: how to get rid of nasty compiler warning in boost/property_tree/detail/rapidxml.hpp Wed, 29 Jun 2011 07:39:25 GMT Fri, 14 Feb 2014 15:10:46 GMT <p> compiling e.g libs/graph/src/graphml.cpp warns ... </p> <pre class="wiki">/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&lt;Ch&gt;::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&lt;Ch&gt;::skip(Ch*&amp;) [with Stop Pred = boost::property_tree::detail::rapidxml::xml_document&lt;char&gt;::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&lt;Ch&gt;::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&lt; typename Ptree::key_type::value_type, std::char_traits&lt;typename Ptree::key_type: :value_type&gt; &gt;&amp;, Ptree&amp;, int, const std::string&amp;) [with Ptree = boost::property_ tree::basic_ptree&lt;std::string, std::string, std::less&lt;std::string&gt; &gt;]' ./boost/property_tree/xml_parser.hpp:52: instantiated from `void boost::proper ty_tree::xml_parser::read_xml(std::basic_istream&lt;typename Ptree::key_type::value _type, std::char_traits&lt;typename Ptree::key_type::value_type&gt; &gt;&amp;, Ptree&amp;, 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 </pre><p> Caused by the template: </p> <pre class="wiki">template&lt;class Ch&gt; inline size_t get_index(const Ch c) { // If not ASCII char, its sematic is same as plain 'z' if (c &gt; 255) { return 'z'; } return c; } </pre><p> How to avoid ? Just specify additionally a user defined implementation of get_index for the "char" type : </p> <pre class="wiki"> inline size_t get_index(const char c) { return c; } template&lt;class Ch&gt; inline size_t get_index(const Ch c) { // If not ASCII char, its sematic is same as plain 'z' if (c &gt; 255) { return 'z'; } return c; } </pre><p> I checked the code size (using gcc4.0) : same and the difference of the ASM code: "same" </p> <pre class="wiki">14972c14972 &lt; cmpq (%r15), %rdi --- &gt; cmpq %rdi, (%r15) 14974c14974 &lt; jae .L3637 --- &gt; jbe .L3637 15002c15002 &lt; cmpq -16(%rsi), %rdi --- &gt; cmpq %rdi, -16(%rsi) 15004c15004 &lt; jae .L3643 --- &gt; jbe .L3643 15017c15017 &lt; cmpq -16(%rdx), %rdi --- &gt; cmpq %rdi, -16(%rdx) 15019c15019 &lt; jb .L3796 --- &gt; ja .L3796 15487c15487 --- </pre> Dieter Stach <Dieter.Stach@…> https://svn.boost.org/trac10/ticket/5658 https://svn.boost.org/trac10/ticket/5658 Report #8565: Lists in admonitions Mon, 13 May 2013 11:12:38 GMT Sun, 29 Sep 2013 11:35:22 GMT <p> It seems not to be possible to include lists in admonitions. </p> <p> E.g. the following won't work, meaning no list will be displayed but just the stars as characters: </p> <p> [note Some text for my note </p> <ul><li>first point I want to note </li><li>second point I want to note </li></ul><p> ] </p> thomas.moeck@… https://svn.boost.org/trac10/ticket/8565 https://svn.boost.org/trac10/ticket/8565 Report #1558: Optional separate compilation Sun, 06 Jan 2008 18:41:53 GMT Sat, 21 Feb 2009 18:17:31 GMT <p> There are some parts of Boost.Unordered that could be compiled into a library file. Provide an option to do this. </p> Daniel James https://svn.boost.org/trac10/ticket/1558 https://svn.boost.org/trac10/ticket/1558 Report #1979: More example hash functions Sun, 01 Jun 2008 10:17:27 GMT Sat, 21 Feb 2009 18:17:46 GMT Daniel James https://svn.boost.org/trac10/ticket/1979 https://svn.boost.org/trac10/ticket/1979 Report #2448: syntax highlighting for code in documentation or website Wed, 29 Oct 2008 19:56:48 GMT Sat, 21 Feb 2009 17:15:22 GMT <p> 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. </p> hagai26@… https://svn.boost.org/trac10/ticket/2448 https://svn.boost.org/trac10/ticket/2448 Report #8545: Can quickbook support parts and chapters as well as sections? Fri, 03 May 2013 15:56:14 GMT Mon, 06 May 2013 16:38:17 GMT <p> 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 &lt;para&gt;...&lt;/para&gt; wrapped around them even when they're block templates. </p> John Maddock https://svn.boost.org/trac10/ticket/8545 https://svn.boost.org/trac10/ticket/8545 Report #1175: Document quickbook's (lack of) unicode support. Mon, 13 Aug 2007 11:23:21 GMT Sat, 06 Jun 2009 13:47:40 GMT <p> See <a class="ext-link" href="http://tinyurl.com/35j57v"><span class="icon">​</span>http://tinyurl.com/35j57v</a> </p> Joel de Guzman https://svn.boost.org/trac10/ticket/1175 https://svn.boost.org/trac10/ticket/1175 Report #1279: Make sure multiple #import of a file imports the file only once. Mon, 24 Sep 2007 06:37:48 GMT Sun, 29 Sep 2013 11:21:32 GMT Joel de Guzman https://svn.boost.org/trac10/ticket/1279 https://svn.boost.org/trac10/ticket/1279 Report #1487: Update the writing documentation instructions Fri, 30 Nov 2007 20:01:35 GMT Mon, 07 Jun 2010 22:40:00 GMT <p> The documentation (<a href="http://www.boost.org/more/writingdoc/structure.html">http://www.boost.org/more/writingdoc/structure.html</a>) needs to updated and probably should be moved to the new site. </p> Daniel James https://svn.boost.org/trac10/ticket/1487 https://svn.boost.org/trac10/ticket/1487 Report #4442: Simple implementation of operator * for matrices with 0 complexity Thu, 15 Jul 2010 22:47:25 GMT Thu, 01 Aug 2013 12:18:50 GMT <p> The following is a simple implementation of operator * for matrix-matrix and matrix-vector which simply forwards to the existing prod() implementation. </p> <p> Since nested products A * B * C can't work yet, it does a compile time check to make sure this isn't occuring. </p> <p> See attached patch and test file. Note that this also has patched changes for ticket <a class="new ticket" href="https://svn.boost.org/trac10/ticket/4441" title="#4441: Bugs: SFINAE for operator * breaking auto differentiation code (new)">#4441</a> built in </p> Jesse Perla <jesseperla@…> https://svn.boost.org/trac10/ticket/4442 https://svn.boost.org/trac10/ticket/4442 Report #3936: [xpressive] stack overflow. Tue, 16 Feb 2010 14:56:20 GMT Wed, 17 Feb 2010 00:06:35 GMT <p> The following simple program fires a stack overflow exception in xpressive. It's seems too simple to be causing such problems. </p> <p> {{{#include "stdafx.h" #include &lt;string&gt; #include &lt;boost/xpressive/xpressive.hpp&gt; using namespace boost::xpressive; </p> <p> int _tmain(int argc, _TCHAR* argv[]) { </p> <blockquote> <p> sregex rx = ~(set='{', '}', ','); sregex rx2 = +rx; </p> </blockquote> <blockquote> <p> std::string s(10000, 'a'); regex_search(s, rx2); </p> </blockquote> <blockquote> <p> return 0; </p> </blockquote> <p> }}}} </p> <p> I'm using MSVC 2005. The problem only occurs if the string is large. </p> shewitt.au@… https://svn.boost.org/trac10/ticket/3936 https://svn.boost.org/trac10/ticket/3936 Report #6992: accumulator's median feature skips 1st two data points. Sat, 16 Jun 2012 01:10:15 GMT Wed, 14 Dec 2016 11:44:04 GMT <p> Hi, </p> <p> 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. </p> <p> Please check what is going on. </p> <p> Thanks, yu </p> polyactis@… https://svn.boost.org/trac10/ticket/6992 https://svn.boost.org/trac10/ticket/6992 Report #3519: It should be possible to use consts as external placeholder variables. Mon, 12 Oct 2009 15:26:05 GMT Wed, 06 Oct 2010 18:18:53 GMT <p> The right-and-side of placeholder let-expressions are not declared as const, so common use-cases like: </p> <p> </p> <pre class="wiki">placeholder&lt;int&gt; _i; smatch what; what.let(_i = 1); </pre><p> or: </p> <p> </p> <pre class="wiki">placeholder&lt;MyClass *&gt; _p; smatch what; what.let(_p = this); </pre><p> fail to compile. It would be nice to have some way to specify a placeholder for non-mutable data. Perhaps: </p> <pre class="wiki">placeholder&lt;int const&gt; _i; </pre><p> (suggested by Eric Niebler) </p> ami.ganguli@… https://svn.boost.org/trac10/ticket/3519 https://svn.boost.org/trac10/ticket/3519 Report #4704: Support for multicapture and balancing groups Sun, 03 Oct 2010 09:05:25 GMT Thu, 29 Jun 2017 18:58:58 GMT <p> Feature request ticked to jog Eric Nieblers memory to take a look at some code. </p> <p> I've added support for multicapture and balancing groups to Boost::Xpressive. </p> <p> Syntax for pop capture: </p> <blockquote> <p> dynamic: (?P&lt;-name&gt;stuff)<br /> static: (name -= stuff) </p> </blockquote> <p> Syntax for capture conditional: </p> <blockquote> <p> dynamic: (?P(name)stuff)<br /> static: (name &amp;= stuff) </p> </blockquote> <p> The changes are in the vault and can be found here: <a class="ext-link" href="http://tinyurl.com/3aak7mp"><span class="icon">​</span>http://tinyurl.com/3aak7mp</a> </p> <p> 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. </p> <p> Erik Rydgren </p> erik@… https://svn.boost.org/trac10/ticket/4704 https://svn.boost.org/trac10/ticket/4704 Report #6891: Add extension point to define how expressions are created from operators Sat, 12 May 2012 16:15:55 GMT Wed, 06 Jun 2012 17:39:53 GMT <p> As discussed here: &lt;<a class="ext-link" href="http://lists.boost.org/proto/2012/05/0637.php"><span class="icon">​</span>http://lists.boost.org/proto/2012/05/0637.php</a>&gt; </p> <p> 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. </p> Mathias Gaunard https://svn.boost.org/trac10/ticket/6891 https://svn.boost.org/trac10/ticket/6891 Report #4668: Conditions for operator overload in Proto (documentation) Tue, 21 Sep 2010 20:00:16 GMT Wed, 06 Oct 2010 18:18:11 GMT <p> Taken from this thread in boost-users: <a class="ext-link" href="http://lists.boost.org/boost-users/2010/09/62747.php"><span class="icon">​</span>http://lists.boost.org/boost-users/2010/09/62747.php</a> </p> <p> This explanation by Thomas Heller would make a good section for the proto documentation: </p> <pre class="wiki">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. </pre><p> To illustrate what this means, this minimalistic example might be useful, too: </p> <p> This grammar </p> <pre class="wiki">proto::plus&lt;proto::terminal&lt;int&gt;, proto::terminal&lt;int&gt; &gt; </pre><p> used in a domain would not allow </p> <pre class="wiki">i + i; </pre><p> with i being an int-terminal. </p> Roland Bock <rbock@…> https://svn.boost.org/trac10/ticket/4668 https://svn.boost.org/trac10/ticket/4668 Report #12880: Alignment information @ PP time Wed, 01 Mar 2017 14:42:25 GMT Fri, 03 Mar 2017 13:37:23 GMT <p> Please add a macro that can be used for selective compilation based on the guaranteed alignment of the default allocator, i.e. something like: <a class="ext-link" href="https://bitbucket.org/eigen/eigen/src/d4e10456d28275c27f417efc119024749c979b7e/Eigen/src/Core/util/Memory.h"><span class="icon">​</span>https://bitbucket.org/eigen/eigen/src/d4e10456d28275c27f417efc119024749c979b7e/Eigen/src/Core/util/Memory.h</a> </p> Domagoj Šarić https://svn.boost.org/trac10/ticket/12880 https://svn.boost.org/trac10/ticket/12880 Report #2692: No concepts supporting the idea of dense Wed, 28 Jan 2009 20:51:45 GMT Thu, 18 Jun 2009 08:01:37 GMT <p> data() returns a reference to a Storage. However, nowhere in the concepts is a statement saying that &amp;m.data()<a class="missing changeset" title="No changeset 0 in the repository">[0]</a> 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&lt;T&gt;::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&lt;bool&gt;. 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 &amp;v[i+j] == &amp;v[i]+j (for reasonable i+j). </p> dougrm@… https://svn.boost.org/trac10/ticket/2692 https://svn.boost.org/trac10/ticket/2692 Report #3396: add a sparse_view class that wraps pre-allocated data into a matrix expression Thu, 03 Sep 2009 20:16:06 GMT Tue, 06 Oct 2009 23:13:48 GMT <p> Provide a way to use ublas with pre-allocated data. Implement a matrix view of a CRS matrix as proof of concept. Details: </p> <ul><li>given 3 arrays: row pointers, column indices, values (<a class="ext-link" href="http://www.netlib.org/utk/papers/templates/node90.html"><span class="icon">​</span>http://www.netlib.org/utk/papers/templates/node90.html</a>) </li></ul><ul><li>provide a wrapper that fulfills the immutable part of the matrix expression </li></ul><p> Further tasks: </p> <ul><li>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 </li></ul><ul><li>improve traits mechanism and apply it where possible to automatically see a fixed size C-array as vector view or matrix view </li></ul><ul><li>add necessary tests </li></ul> Gunter https://svn.boost.org/trac10/ticket/3396 https://svn.boost.org/trac10/ticket/3396 Report #4033: optimized matrix products Mon, 22 Mar 2010 21:38:27 GMT Mon, 29 Mar 2010 06:58:56 GMT <p> proposal from Jörn Ungermann: </p> <p> <strong>Abstract</strong> </p> <p> 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. </p> <p> <strong>Details</strong> </p> <p> 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. </p> <p> 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. </p> <p> In fact, I'd propose to have two sets of interfaces: </p> <p> 1) One convenient one, possibly compromising efficiency <br /> 2) One modeled closely after C-BLAS, delivering utmost efficiency. </p> <p> 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. </p> <p> 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). </p> <p> 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. </p> <p> 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. </p> <p> Larger matrix sizes result in prohibitive runtimes for the "slow" products, but can be used to analyse pure-sparse products. </p> <p> The runtime shall be taken only qualitatively. </p> <p> 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. </p> <p> 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. </p> Gunter https://svn.boost.org/trac10/ticket/4033 https://svn.boost.org/trac10/ticket/4033 Report #1915: Nested matrix products with transposes causes compiler to complain error: invalid application of ‘sizeof’ Wed, 14 May 2008 05:52:05 GMT Wed, 14 May 2008 21:56:28 GMT <p> When using ublas, a pair of nested products will cause the compiler to complain if there is a <code>trans</code> on any of the operands. For example: </p> <div class="wiki-code"><div class="code"><pre><span class="k">using</span> <span class="k">namespace</span> <span class="n">boost</span><span class="o">::</span><span class="n">numeric</span><span class="o">::</span><span class="n">ublas</span><span class="p">;</span> <span class="n">matrix</span><span class="o">&lt;</span><span class="kt">float</span><span class="o">&gt;</span> <span class="n">A</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span><span class="mi">3</span><span class="p">),</span> <span class="n">B</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span><span class="mi">3</span><span class="p">),</span> <span class="n">C</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span><span class="mi">3</span><span class="p">);</span> <span class="n">prod</span><span class="p">(</span><span class="n">prod</span><span class="p">(</span><span class="n">A</span><span class="p">,</span><span class="n">B</span><span class="p">),</span><span class="n">trans</span><span class="p">(</span><span class="n">C</span><span class="p">));</span> <span class="c1">// fails</span> <span class="n">prod</span><span class="p">(</span><span class="n">prod</span><span class="p">(</span><span class="n">trans</span><span class="p">(</span><span class="n">A</span><span class="p">),</span><span class="n">B</span><span class="p">),</span><span class="n">C</span><span class="p">);</span> <span class="c1">// fails</span> <span class="n">prod</span><span class="p">(</span><span class="n">prod</span><span class="p">(</span><span class="n">A</span><span class="p">,</span><span class="n">trans</span><span class="p">(</span><span class="n">B</span><span class="p">)),</span><span class="n">C</span><span class="p">);</span> <span class="c1">// fails</span> <span class="n">prod</span><span class="p">(</span><span class="n">prod</span><span class="p">(</span><span class="n">A</span><span class="p">,</span><span class="n">B</span><span class="p">),</span><span class="n">C</span><span class="p">);</span> <span class="c1">// OK</span> </pre></div></div><p> The compiler produces the following error message: </p> <pre class="wiki">/opt/local/include/boost/numeric/ublas/matrix_expression.hpp: In function ‘typename boost::numeric::ublas::matrix_matrix_binary_traits&lt;typename E1::value_type, E1, typename E2::value_type, E2&gt;::result_type boost::numeric::ublas::prod(const boost::numeric::ublas::matrix_expression&lt;E&gt;&amp;, const boost::numeric::ublas::matrix_expression&lt;E2&gt;&amp;) [with E1 = boost::numeric::ublas::matrix_matrix_binary&lt;boost::numeric::ublas::matrix&lt;float, boost::numeric::ublas::basic_row_major&lt;size_t, ptrdiff_t&gt;, boost::numeric::ublas::unbounded_array&lt;float, std::allocator&lt;float&gt; &gt; &gt;, boost::numeric::ublas::matrix&lt;float, boost::numeric::ublas::basic_row_major&lt;size_t, ptrdiff_t&gt;, boost::numeric::ublas::unbounded_array&lt;float, std::allocator&lt;float&gt; &gt; &gt;, boost::numeric::ublas::matrix_matrix_prod&lt;float, float, float&gt; &gt;, E2 = boost::numeric::ublas::matrix_unary2&lt;boost::numeric::ublas::matrix&lt;float, boost::numeric::ublas::basic_row_major&lt;size_t, ptrdiff_t&gt;, boost::numeric::ublas::unbounded_array&lt;float, std::allocator&lt;float&gt; &gt; &gt;, boost::numeric::ublas::scalar_identity&lt;float&gt; &gt;]’: 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&lt;false&gt;’ </pre> Leo Singer <aronnax@…> https://svn.boost.org/trac10/ticket/1915 https://svn.boost.org/trac10/ticket/1915 Report #6545: boost:::python doesn't recognize std::shared_ptr Sat, 11 Feb 2012 14:03:12 GMT Fri, 18 Sep 2015 07:17:12 GMT <p> boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr </p> Neal Becker <ndbecker2@…> https://svn.boost.org/trac10/ticket/6545 https://svn.boost.org/trac10/ticket/6545 Report #3077: Reverse iterator compile-time bug in multi_array Mon, 25 May 2009 10:47:28 GMT Tue, 08 Jun 2010 22:51:47 GMT <p> 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: </p> <pre class="wiki">#include &lt;boost/multi_array.hpp&gt; template&lt; typename It &gt; void iterate_over( It begin, It end ) { while( end != begin ) { begin-&gt;end() - begin-&gt;begin(); ++begin; } } void test() { boost::multi_array&lt; double, 2 &gt; m; iterate_over( m.begin(), m.end() ); // works fine iterate_over( m.rbegin(), m.rend() ); // causes error } </pre><p> 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-&gt; is used. The (*begin). notation works fine. </p> <p> /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp: In static member function ‘static typename boost::mpl::if_&lt;boost::is_reference&lt;Reference&gt;, Pointer, boost::detail::operator_arrow_proxy&lt;<a class="missing wiki">ValueType</a>&gt; &gt;::type boost::detail::operator_arrow_result&lt;<a class="missing wiki">ValueType</a>, Reference, Pointer&gt;::make(Reference) [with <a class="missing wiki">ValueType</a> = boost::multi_array&lt;double, 1ul, std::allocator&lt;double&gt; &gt;, Reference = boost::detail::multi_array::sub_array&lt;double, 1ul&gt;, Pointer = boost::multi_array&lt;double, 1ul, std::allocator&lt;double&gt; &gt;*]’: /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:648: instantiated from ‘typename boost::detail::operator_arrow_result&lt;typename boost::detail::iterator_facade_types&lt;Value, <a class="missing wiki">CategoryOrTraversal</a>, Reference, Difference&gt;::value_type, Reference, typename boost::detail::iterator_facade_types&lt;Value, <a class="missing wiki">CategoryOrTraversal</a>, Reference, Difference&gt;::pointer&gt;::type boost::iterator_facade&lt;I, V, TC, R, D&gt;::operator-&gt;() const [with Derived = boost::reverse_iterator&lt;boost::detail::multi_array::array_iterator&lt;double, double*, mpl_::size_t&lt;2ul&gt;, boost::detail::multi_array::sub_array&lt;double, 1ul&gt; &gt; &gt;, Value = boost::multi_array&lt;double, 1ul, std::allocator&lt;double&gt; &gt;, <a class="missing wiki">CategoryOrTraversal</a> = boost::detail::iterator_category_with_traversal&lt;std::input_iterator_tag, boost::random_access_traversal_tag&gt;, Reference = boost::detail::multi_array::sub_array&lt;double, 1ul&gt;, Difference = long int]’ src/sandbox/seqan_sandbox.cpp:12: instantiated from ‘void iterate_over(It, It) [with It = boost::reverse_iterator&lt;boost::detail::multi_array::array_iterator&lt;double, double*, mpl_::size_t&lt;2ul&gt;, boost::detail::multi_array::sub_array&lt;double, 1ul&gt; &gt; &gt;]’ 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&lt;double, 1ul&gt;*)’ </p> John Reid <john.reid@…> https://svn.boost.org/trac10/ticket/3077 https://svn.boost.org/trac10/ticket/3077 Report #5636: BGL isomorphism vertex invariant interface change Thu, 23 Jun 2011 22:48:35 GMT Fri, 29 Jul 2011 02:26:06 GMT <p> (This is the last isomorphism ticket I think. :-)) </p> <p> I have one more suggestion about how to handle vertex invariants. To determine whether <code>u</code> and <code>v</code> should be considered equivalent by the isomorphism, instead of providing two functors <code>f</code> and <code>g</code>, calling <code>f(u)</code> and <code>g(v)</code> to get a pair of integers, and finally comparing the result, I think it would be cleaner to have a "binary" predicate <code>p</code> which would be called as <code>p(u,v)</code>. (In reality of course you'd probably want to have it receive <code>g1</code> and <code>g2</code> as well, so it'd really be a 4-arg function.) This should also let you get rid of the <code>vertex_max_invariant</code> parameter perhaps. </p> <p> 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<sup>2 traversal and recording for each <code>u</code> in <code>g1</code> how many <code>v</code>s in <code>g2</code> are considered equivalent. This is a bit different from what you're doing now, I think. </sup></p> <p> (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 <code>vertex_max_invariant</code>, so you can't even use all that much of that size -- you can just test it directly.) </p> Evan Driscoll <driscoll@…> https://svn.boost.org/trac10/ticket/5636 https://svn.boost.org/trac10/ticket/5636 Report #6893: Inaccurate Radians/Degrees conversion Sun, 13 May 2012 10:19:17 GMT Sun, 08 Jul 2018 16:19:39 GMT <p> LS, </p> <p> 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... </p> <p> This is unnecessarily inaccurate (only 14 significant digits are correct) and gives problems in my application - the actual value reads: 0.017453292519943295769236907684886127134428718885417... </p> <p> Using this value improves conversion accuracy significantly. </p> <p> Please consider using this more accurate value. Alternatively, the use of boost::math::constants could be considered, making the factor: boost::math::constants::pi&lt;double&gt;()/180.0 which works fine as well. </p> pieterb@… https://svn.boost.org/trac10/ticket/6893 https://svn.boost.org/trac10/ticket/6893 Report #2801: gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long) Wed, 25 Feb 2009 20:54:04 GMT Thu, 18 Jan 2018 14:19:55 GMT <p> 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. </p> <p> 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: </p> <pre class="wiki"> template&lt;typename ymd_type_, typename date_int_type_&gt; BOOST_DATE_TIME_INLINE int gregorian_calendar_base&lt;ymd_type_,date_int_type_&gt;::week_number(const ymd_type&amp; 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 &gt;= 1) &amp;&amp; (week &lt;= 52)) { return static_cast&lt;int&gt;(week); } if ((week == 53)) { if((day==6) ||(day == 5 &amp;&amp; is_leap_year(ymd.year))) { return static_cast&lt;int&gt;(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&lt;unsigned short&gt;(ymd.year-1),1,1)); juliantoday = julian_day_number(ymd); day = (julianbegin + 3) % 7; week = (juliantoday + day - julianbegin + 4)/7; return static_cast&lt;int&gt;(week); } return static_cast&lt;int&gt;(week); //not reachable -- well except if day == 5 and is_leap_year != true } </pre> pelee@… https://svn.boost.org/trac10/ticket/2801 https://svn.boost.org/trac10/ticket/2801 Report #10285: local_time is not monotonic Fri, 01 Aug 2014 08:03:44 GMT Sat, 06 Jan 2018 15:43:11 GMT <p> The following snippet seems to generate non monotonic local_date. </p> <p> I'm using boost 1.55 on linux. </p> <p> #include &lt;boost/date_time/local_time/local_time.hpp&gt; #include &lt;boost/ptr_container/ptr_vector.hpp&gt; </p> <p> int main() { </p> <blockquote> <p> const boost::local_time::time_zone_ptr theTimeZone( </p> <blockquote> <p> new boost::local_time::posix_time_zone( </p> <blockquote> <p> "CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00") </p> </blockquote> </blockquote> <p> ); </p> </blockquote> <blockquote> <p> boost::local_time::local_date_time myOldValue( </p> <blockquote> <p> boost::local_time::local_microsec_clock::local_time(theTimeZone)); </p> </blockquote> </blockquote> <blockquote> <p> for (size_t i = 0; ; ++i) { </p> <blockquote> <p> const boost::local_time::local_date_time myLocalTime = </p> <blockquote> <p> boost::local_time::local_microsec_clock::local_time(theTimeZone); </p> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <p> if (myLocalTime &lt; myOldValue) { </p> <blockquote> <p> std::cout &lt;&lt; myOldValue &lt;&lt; std::endl; std::cout &lt;&lt; myLocalTime &lt;&lt; std::endl; std::cout &lt;&lt; boost::local_time::local_microsec_clock::local_time(theTimeZone) &lt;&lt; std::endl; std::cout &lt;&lt; "====================" &lt;&lt; std::endl; </p> </blockquote> <p> } </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> myOldValue = myLocalTime; </p> </blockquote> <p> } </p> </blockquote> <p> } </p> <p> As you can see the program is not supposed to print anything ever, however this is what I'm getting: </p> <p> 2014-Jul-31 00:24:56.005625 CEST 2014-Jul-31 00:24:55.005631 CEST &lt;== 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 &lt;== 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 &lt;== 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 &lt;== 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 &lt;== 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 &lt;== 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 &lt;== 1 second back 2014-Jul-31 00:25:12.005822 CEST ==================== </p> <p> 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. </p> Gaetano Mendola <mendola@…> https://svn.boost.org/trac10/ticket/10285 https://svn.boost.org/trac10/ticket/10285 Report #11067: boost::gregorian::date_iterator missing postfix operators ++ and -- Tue, 03 Mar 2015 16:29:10 GMT Thu, 28 Dec 2017 13:35:12 GMT <p> /* Consider the following (somewhat canonical) code snippet */ { </p> <blockquote> <p> std::vector&lt;boost::gregorian::date&gt; dates(count); auto dt_i = dates.begin(); boost::gregorian::month_iterator m_i(some_start_date, 1); </p> </blockquote> <blockquote> <p> while (dt_i != dts.end()) </p> <blockquote> <p> *dt_i++ = *m_i++; /* this will call prefix ++ operator on m_i </p> <blockquote> <p> leading to subtle bug */ </p> </blockquote> </blockquote> </blockquote> <p> } </p> dkochin@… https://svn.boost.org/trac10/ticket/11067 https://svn.boost.org/trac10/ticket/11067 Report #10103: setprecision(0) does displays too many digits of a float128 Sat, 07 Jun 2014 12:38:29 GMT Wed, 14 Oct 2015 14:40:49 GMT <p> setprecision(0) is not honored for float128. Compare the display of a double and a float128 (default and fixed): </p> <pre class="wiki">0.1 0.123400000000000000000000000000000006 0 0.123400000000000000000000000000000006 </pre><p> This is produced with </p> <pre class="wiki">#include &lt;iostream&gt; #include &lt;boost/multiprecision/float128.hpp&gt; int main() { double x = 0.1234; boost::multiprecision::float128 y = 0.1234Q; std::cout &lt;&lt; std::setprecision(0) &lt;&lt; x &lt;&lt; " " &lt;&lt; y &lt;&lt; "\n"; std::cout &lt;&lt; std::fixed &lt;&lt; x &lt;&lt; " " &lt;&lt; y &lt;&lt; "\n"; } </pre> Charles Karney <charles@…> https://svn.boost.org/trac10/ticket/10103 https://svn.boost.org/trac10/ticket/10103 Report #3408: gamma distribution's quantile performance Sun, 06 Sep 2009 18:50:32 GMT Tue, 06 Oct 2009 17:13:28 GMT <p> 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: </p> <p> <a class="ext-link" href="http://people.sc.fsu.edu/~burkardt/cpp_src/dcdflib/dcdflib.html"><span class="icon">​</span>http://people.sc.fsu.edu/~burkardt/cpp_src/dcdflib/dcdflib.html</a> </p> <p> The old source code is about 2x times faster than the boost version. </p> <p> MS Visual Studio 2005: boost: 35.4sec att_bell:19sec </p> <p> Intel 11.1: boost: 21.4sec att_bell: 11.2sec </p> <p> 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. </p> <p> Here the code: </p> <p> #include &lt;dcdflib.h&gt; </p> <p> #include &lt;boost/math/distributions/gamma.hpp&gt; </p> <p> #include &lt;boost/timer.hpp&gt; </p> <p> double min_mean = 2000; <em> 2,000 double max_mean = 500000000; </em>500,000,000 </p> <p> double min_std = 10000; <em> 10,000 double max_std = 100000000; </em> 100,000,000 </p> <p> double min_max = 600000000; <em> 600,000,000 double max_max = 1000000000; </em> 1,000,000,000 </p> <p> const std::size_t max_year = 5000000; <em> 5,000,000 </em></p> <p> const double right = 0.999; const double left = 0.001; </p> <p> inline double get_rand() { </p> <blockquote> <p> return static_cast&lt; double &gt;( std::rand() ) </p> <blockquote> <p> / static_cast&lt; double &gt;( RAND_MAX ); </p> </blockquote> </blockquote> <p> } </p> <p> inline void boost_( boost::math::gamma_distribution&lt;&gt;&amp; d, double q ) { </p> <blockquote> <p> double value = boost::math::quantile( d, q ); </p> </blockquote> <p> } </p> <p> inline void att_bell( double alpha, double beta, double q ) { </p> <blockquote> <p> double q_Minus1 = 1 - q; double value = 0.0; double bound = 0.0; </p> </blockquote> <blockquote> <p> int which = 2; int status = 0; </p> </blockquote> <blockquote> <p> cdfgam( &amp;which </p> <blockquote> <p> , &amp;q , &amp;q_Minus1 , &amp;value , &amp;alpha , &amp;beta , &amp;status , &amp;bound ); </p> </blockquote> </blockquote> <p> } </p> <p> int main() { </p> <blockquote> <p> <em> boost { </em></p> <blockquote> <p> std::srand( 0 ); </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> boost::timer timer; for( std::size_t y = 0; y &lt; max_year; ++y ) { </p> <blockquote> <p> if(( y % 100000 ) == 0 ) </p> <blockquote> <p> std::cout &lt;&lt; y &lt;&lt; std::endl; </p> </blockquote> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std; </p> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> double alpha = mean * mean / std / std; <em> shape parameter double beta = mean / alpha; </em> scale parameter </p> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> boost::math::gamma_distribution&lt;&gt; d( alpha, beta ); boost_( d, right ); boost_( d, left ); </p> </blockquote> <p> } </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> std::cout &lt;&lt; "Boost - Time elapsed: " &lt;&lt; timer.elapsed() &lt;&lt; " </p> </blockquote> </blockquote> <p> sec" &lt;&lt; std::endl; </p> <blockquote> <p> } </p> </blockquote> <blockquote> <p> <em> att bell { </em></p> <blockquote> <p> std::srand( 0 ); </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> boost::timer timer; for( std::size_t y = 0; y &lt; max_year; ++y ) { </p> <blockquote> <p> if(( y % 100000 ) == 0 ) </p> <blockquote> <p> std::cout &lt;&lt; y &lt;&lt; std::endl; </p> </blockquote> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std; </p> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> double alpha = mean * mean / std / std; <em> shape parameter double beta = mean / alpha; </em> scale parameter </p> </blockquote> </blockquote> </blockquote> <blockquote> <blockquote> <blockquote> <p> att_bell( alpha, beta, right ); att_bell( alpha, beta, left ); </p> </blockquote> <p> } </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> std::cout &lt;&lt; "ATT Bell - Time elapsed: " &lt;&lt; timer.elapsed() &lt;&lt; </p> </blockquote> </blockquote> <p> " sec" &lt;&lt; std::endl; </p> <blockquote> <p> } </p> </blockquote> <blockquote> <p> return 0; </p> </blockquote> <p> } </p> chhenning@… https://svn.boost.org/trac10/ticket/3408 https://svn.boost.org/trac10/ticket/3408 Report #10946: Add dt to system arguments Tue, 20 Jan 2015 17:25:03 GMT Thu, 29 Jan 2015 21:29:57 GMT <p> 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. </p> <p> (1) Equations 25 and 26 in (h)ttp://www.dtic.mil/dtic/tr/fulltext/u2/a023511.pdf </p> ilja.j.honkonen@… https://svn.boost.org/trac10/ticket/10946 https://svn.boost.org/trac10/ticket/10946 Report #7494: boost::replace_all is very slow on debug build when Format size is big Thu, 11 Oct 2012 09:28:38 GMT Mon, 11 Jul 2016 21:34:40 GMT <p> Method boost::replace_all(SequenceT&amp; Input, const Range1T&amp; Search, const Range2T&amp; 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. </p> <p> When I use std::find and std::replace in loop it is cca 10 times faster. </p> <p> I have Boost library 1.45, Visual Studio 2010, Win7 x64 SP1, 6-core CPU. </p> Jan Vonasek <jan.vonasek@…> https://svn.boost.org/trac10/ticket/7494 https://svn.boost.org/trac10/ticket/7494 Report #6160: support for (istream >> array < char >) Tue, 22 Nov 2011 00:38:37 GMT Mon, 28 Nov 2011 17:17:25 GMT <ol><li><code>array &lt; T &gt;</code> is a replacement for <code>T []</code> </li><li>the standard library provides the syntax <code>(istream &gt;&gt; char [])</code> and <code>(ostream &lt;&lt; char const [])</code> </li><li>Currently, <code>(istream &gt;&gt; array &lt; char &gt;)</code> does not mean anything </li><li>this functionality cannot be simulated even with <code>std:: copy_n &lt; istreambuf_iterator &gt;</code> without manual termination and much verbosity </li></ol><h2 class="section" id="Myimplementation">My implementation</h2> <div class="wiki-code"><div class="code"><pre> <span class="cp">#include</span> <span class="cpf">&lt;boost/array.hpp&gt; /* for ::boost:: array */</span><span class="cp"></span> <span class="cp">#include</span> <span class="cpf">&lt;boost/version.hpp&gt;</span><span class="cp"></span> <span class="cp">#if +BOOST_VERSION &lt;= 0313720</span> <span class="cp">#include</span> <span class="cpf">&lt;iomanip&gt; /* for ::std:: setw */</span><span class="cp"></span> <span class="k">namespace</span> <span class="n">boost</span> <span class="p">{</span> <span class="cm">/* helper classes to prevent ambiguity in matching array &lt; char &gt; */</span> <span class="k">namespace</span> <span class="n">detail_</span> <span class="p">{</span> <span class="cm">/* normally, other char for every character type is char */</span> <span class="k">template</span> <span class="o">&lt;</span> <span class="k">class</span> <span class="nc">P_C</span> <span class="o">&gt;</span> <span class="k">class</span> <span class="nc">other_char</span> <span class="p">{</span> <span class="k">public</span><span class="o">:</span> <span class="k">typedef</span> <span class="kt">char</span> <span class="n">type</span><span class="p">;</span> <span class="p">};</span> <span class="cm">/* but other_char is undefined for char */</span> <span class="k">template</span> <span class="o">&lt;&gt;</span> <span class="k">class</span> <span class="nc">other_char</span> <span class="o">&lt;</span> <span class="kt">char</span> <span class="o">&gt;</span> <span class="p">{};</span> <span class="cm">/* class same_stream fails for istream */</span> <span class="k">template</span> <span class="o">&lt;</span> <span class="k">class</span> <span class="nc">P_S</span><span class="p">,</span> <span class="k">class</span> <span class="nc">P_C</span> <span class="o">=</span> <span class="k">typename</span> <span class="n">other_char</span> <span class="o">&lt;</span> <span class="k">typename</span> <span class="n">P_S</span><span class="o">::</span> <span class="n">char_type</span> <span class="o">&gt;::</span> <span class="n">type</span> <span class="o">&gt;</span> <span class="k">class</span> <span class="nc">same_stream</span> <span class="p">{</span> <span class="k">public</span><span class="o">:</span> <span class="k">typedef</span> <span class="n">P_S</span> <span class="n">stream</span><span class="p">;</span> <span class="p">};</span> <span class="p">}</span> <span class="cm">/* template input */</span> <span class="k">template</span> <span class="o">&lt;</span> <span class="k">class</span> <span class="nc">P_C</span><span class="p">,</span> <span class="k">class</span> <span class="nc">P_T</span><span class="p">,</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="kt">size_t</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="k">static</span> <span class="kr">inline</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_istream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="k">operator</span> <span class="o">&gt;&gt;</span> <span class="p">(</span><span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_istream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="n">p_s</span><span class="p">,</span> <span class="o">::</span><span class="n">boost</span><span class="o">::</span> <span class="n">array</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="n">p_a</span><span class="p">)</span> <span class="p">{</span> <span class="k">return</span> <span class="n">p_s</span> <span class="o">&gt;&gt;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">setw</span> <span class="p">(</span><span class="n">p_a</span><span class="p">.</span> <span class="n">static_size</span><span class="p">)</span> <span class="o">&gt;&gt;</span> <span class="n">p_a</span><span class="p">.</span> <span class="n">data</span> <span class="p">();</span> <span class="p">}</span> <span class="cm">/* character input, disabled for type char to avoid ambiguity */</span> <span class="k">template</span> <span class="o">&lt;</span> <span class="k">class</span> <span class="nc">P_C</span><span class="p">,</span> <span class="k">class</span> <span class="nc">P_T</span><span class="p">,</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="kt">size_t</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="k">static</span> <span class="kr">inline</span> <span class="k">typename</span> <span class="n">detail_</span><span class="o">::</span> <span class="n">same_stream</span> <span class="o">&lt;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_istream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&gt;::</span> <span class="n">stream</span> <span class="o">&amp;</span><span class="k">operator</span> <span class="o">&gt;&gt;</span> <span class="p">(</span><span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_istream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="n">p_s</span><span class="p">,</span> <span class="o">::</span><span class="n">boost</span><span class="o">::</span> <span class="n">array</span> <span class="o">&lt;</span> <span class="kt">char</span><span class="p">,</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="n">p_a</span><span class="p">)</span> <span class="p">{</span> <span class="k">return</span> <span class="n">p_s</span> <span class="o">&gt;&gt;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">setw</span> <span class="p">(</span><span class="n">p_a</span><span class="p">.</span> <span class="n">static_size</span><span class="p">)</span> <span class="o">&gt;&gt;</span> <span class="n">p_a</span><span class="p">.</span> <span class="n">data</span> <span class="p">();</span> <span class="p">}</span> <span class="cm">/* template output */</span> <span class="k">template</span> <span class="o">&lt;</span> <span class="k">class</span> <span class="nc">P_C</span><span class="p">,</span> <span class="k">class</span> <span class="nc">P_T</span><span class="p">,</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="kt">size_t</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="k">static</span> <span class="kr">inline</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_ostream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="k">operator</span> <span class="o">&lt;&lt;</span> <span class="p">(</span><span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_ostream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="n">p_s</span><span class="p">,</span> <span class="o">::</span><span class="n">boost</span><span class="o">::</span> <span class="n">array</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="k">const</span> <span class="o">&amp;</span><span class="n">p_a</span><span class="p">)</span> <span class="p">{</span> <span class="k">return</span> <span class="n">p_s</span> <span class="o">&lt;&lt;</span> <span class="n">p_a</span><span class="p">.</span> <span class="n">begin</span> <span class="p">();</span> <span class="p">}</span> <span class="cm">/* character output, disabled for type char */</span> <span class="k">template</span> <span class="o">&lt;</span> <span class="k">class</span> <span class="nc">P_C</span><span class="p">,</span> <span class="k">class</span> <span class="nc">P_T</span><span class="p">,</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="kt">size_t</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="k">static</span> <span class="kr">inline</span> <span class="k">typename</span> <span class="n">detail_</span><span class="o">::</span> <span class="n">same_stream</span> <span class="o">&lt;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_ostream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&gt;::</span> <span class="n">stream</span> <span class="o">&amp;</span><span class="k">operator</span> <span class="o">&lt;&lt;</span> <span class="p">(</span><span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">basic_ostream</span> <span class="o">&lt;</span> <span class="n">P_C</span><span class="p">,</span> <span class="n">P_T</span> <span class="o">&gt;</span> <span class="o">&amp;</span><span class="n">p_s</span><span class="p">,</span> <span class="o">::</span><span class="n">boost</span><span class="o">::</span> <span class="n">array</span> <span class="o">&lt;</span> <span class="kt">char</span><span class="p">,</span> <span class="n">P_N</span> <span class="o">&gt;</span> <span class="k">const</span> <span class="o">&amp;</span><span class="n">p_a</span><span class="p">)</span> <span class="p">{</span> <span class="k">return</span> <span class="n">p_s</span> <span class="o">&lt;&lt;</span> <span class="n">p_a</span><span class="p">.</span> <span class="n">begin</span> <span class="p">();</span> <span class="p">}}</span> <span class="cp">#endif </span><span class="cm">/* BOOST_VERSION */</span><span class="cp"></span> <span class="cp">#include</span> <span class="cpf">&lt;cstdlib&gt; /* for EXIT_SUCCESS */</span><span class="cp"></span> <span class="cp">#include</span> <span class="cpf">&lt;cstdio&gt; /* for BUFSIZ */</span><span class="cp"></span> <span class="cp">#include</span> <span class="cpf">&lt;iostream&gt; /* for ::std:: cin */</span><span class="cp"></span> <span class="kt">int</span> <span class="n">main</span> <span class="p">()</span> <span class="p">{</span> <span class="c1">// char (&amp;x) [+BOOST_VERSION] = 0;</span> <span class="cp">#ifdef ARRAY_IN_NATIVE</span> <span class="cm">/* native code */</span> <span class="kt">char</span> <span class="n">t</span> <span class="p">[</span><span class="o">+</span><span class="n">BUFSIZ</span><span class="p">];</span> <span class="k">return</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">cin</span> <span class="o">&gt;&gt;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">setw</span> <span class="p">(</span><span class="o">+</span><span class="n">BUFSIZ</span><span class="p">)</span> <span class="o">&gt;&gt;</span> <span class="n">t</span> <span class="o">&amp;&amp;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">cout</span> <span class="o">&lt;&lt;</span> <span class="n">t</span> <span class="o">&lt;&lt;</span> <span class="sc">&#39;\n&#39;</span><span class="o">?</span> <span class="o">+</span><span class="nl">EXIT_SUCCESS</span><span class="p">:</span> <span class="o">+</span><span class="n">EXIT_FAILURE</span><span class="p">;</span> <span class="cp">#else </span><span class="cm">/* ARRAY_IN_NATIVE */</span><span class="cp"></span> <span class="cm">/* equivalent Boost code */</span> <span class="o">::</span><span class="n">boost</span><span class="o">::</span> <span class="n">array</span> <span class="o">&lt;</span> <span class="kt">char</span><span class="p">,</span> <span class="o">+</span><span class="n">BUFSIZ</span> <span class="o">&gt;</span> <span class="n">t</span><span class="p">;</span> <span class="cm">/* check that character input compiles for wchar_t */</span> <span class="p">(</span><span class="kt">void</span><span class="p">)</span> <span class="k">sizeof</span> <span class="p">(</span><span class="n">std</span><span class="o">::</span> <span class="n">wcin</span> <span class="o">&gt;&gt;</span> <span class="n">t</span><span class="p">);</span> <span class="k">return</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">cin</span> <span class="o">&gt;&gt;</span> <span class="n">t</span> <span class="o">&amp;&amp;</span> <span class="o">::</span><span class="n">std</span><span class="o">::</span> <span class="n">cout</span> <span class="o">&lt;&lt;</span> <span class="n">t</span> <span class="o">&lt;&lt;</span> <span class="sc">&#39;\n&#39;</span><span class="o">?</span> <span class="o">+</span><span class="nl">EXIT_SUCCESS</span><span class="p">:</span> <span class="o">+</span><span class="n">EXIT_FAILURE</span><span class="p">;</span> <span class="cp">#endif </span><span class="cm">/* ARRAY_IN_NATIVE */</span><span class="cp"></span> <span class="p">}</span> </pre></div></div> giecrilj@… https://svn.boost.org/trac10/ticket/6160 https://svn.boost.org/trac10/ticket/6160 Report #6683: find family of functions needs const Range1T& Input overloads Tue, 13 Mar 2012 14:16:05 GMT Wed, 14 Mar 2012 08:54:17 GMT <p> 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&lt;&gt; that's returned can modify Input. In the spirit of std &amp; the rest of boost I propose an overload which returns const_iterator_range&lt;&gt;, which would provide the same functionality as iterator_range&lt;&gt; save for being able to modify the source. </p> sairony@… https://svn.boost.org/trac10/ticket/6683 https://svn.boost.org/trac10/ticket/6683 Report #6793: Support construction from range Sat, 14 Apr 2012 20:46:23 GMT Mon, 17 Dec 2012 17:31:46 GMT <p> 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. </p> Olaf van der Spek <olafvdspek@…> https://svn.boost.org/trac10/ticket/6793 https://svn.boost.org/trac10/ticket/6793 Report #7652: compile-time checked access Tue, 06 Nov 2012 06:56:56 GMT Tue, 12 Feb 2013 18:11:23 GMT <p> Since code like </p> <p> boost::array&lt;int,2&gt; test; test<a class="changeset" href="https://svn.boost.org/trac10/changeset/2" title="Add Boost Disclaimer">[2]</a> = 1; test[-1] = 1; </p> <p> compiles correctly on some compilers (even without warnings). I suggest adding compile checked functions for static access to arrays like: </p> <blockquote> <p> template&lt;size_type i&gt; reference at() { </p> <blockquote> <p> BOOST_STATIC_ASSERT( (i &lt; N) ); return elems[i]; </p> </blockquote> <p> } </p> </blockquote> <blockquote> <p> template&lt;size_type i&gt; const_reference at() const { </p> <blockquote> <p> BOOST_STATIC_ASSERT( (i &lt; N) ); return elems[i]; </p> </blockquote> <p> } </p> </blockquote> <p> then code like: </p> <p> boost::array&lt;int,2&gt; test; test.at&lt;2&gt; = 1; test.at&lt;-1&gt; = 1; </p> <p> would result in the expected errors. </p> Tobias Loew https://svn.boost.org/trac10/ticket/7652 https://svn.boost.org/trac10/ticket/7652 Report #9287: Additional string_ref constructors Tue, 22 Oct 2013 09:09:19 GMT Tue, 12 May 2015 00:57:48 GMT <p> From: </p> <ul><li>iterator_range&lt;Char const *&gt; </li><li>std::vector&lt;Char&gt; </li><li>pair of iterators </li></ul> Domagoj Šarić https://svn.boost.org/trac10/ticket/9287 https://svn.boost.org/trac10/ticket/9287 Report #9576: read_until for string_ref Wed, 15 Jan 2014 15:13:20 GMT Fri, 24 Jan 2014 09:04:41 GMT <pre class="wiki">string_ref read_until(string_ref&amp; is, const char* sep); </pre><p> 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. </p> Olaf van der Spek <ml@…> https://svn.boost.org/trac10/ticket/9576 https://svn.boost.org/trac10/ticket/9576 Report #9577: trim_copy doesn't support string_ref Wed, 15 Jan 2014 19:07:55 GMT Mon, 31 Mar 2014 20:00:27 GMT <pre class="wiki">boost::string_ref z = " AA BB "; boost::string_ref b = boost::trim_copy(z); </pre><p> does not compile </p> ml@… https://svn.boost.org/trac10/ticket/9577 https://svn.boost.org/trac10/ticket/9577 Report #10983: box-box distance doesn't seem to work with spherical coordinate systems Thu, 29 Jan 2015 23:29:45 GMT Mon, 11 May 2015 05:25:04 GMT <p> 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. </p> <p> 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. </p> <p> 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. </p> <p> See example below for problem. </p> <hr /> <pre class="wiki">#include &lt;boost/geometry/geometry.hpp&gt; typedef boost::geometry::model::point&lt;double,2,boost::geometry::cs::cartesian&gt; cartesian_point; typedef boost::geometry::model::point&lt;double,2,boost::geometry::cs::spherical_equatorial&lt;boost::geometry::degree&gt; &gt; spherical_point; int main() { // Works... boost::geometry::model::box&lt;cartesian_point&gt; c_box1, c_box2; boost::geometry::distance(c_box1,c_box2); // Doesn't work! boost::geometry::model::box&lt;spherical_point&gt; s_box1, s_box2; boost::geometry::distance(s_box1,s_box2); return 0; } </pre> mdrinto@… https://svn.boost.org/trac10/ticket/10983 https://svn.boost.org/trac10/ticket/10983 Report #1201: Regexify the syntax highlighter Wed, 22 Aug 2007 23:27:56 GMT Sun, 26 Aug 2007 09:37:26 GMT <p> 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. </p> Joel de Guzman https://svn.boost.org/trac10/ticket/1201 https://svn.boost.org/trac10/ticket/1201 Report #7630: Range adaptors do not play nicely with range-based for loops Fri, 02 Nov 2012 18:37:22 GMT Thu, 02 Jun 2016 23:18:04 GMT <p> Consider the following C++11 code, adapted from the Range documentation: </p> <pre class="wiki">std::vector&lt;int&gt; vec; for (int val : vec | boost::adaptors::reversed | boost::adaptors::uniqued) { // Do stuff with val } </pre><p> The behavior of this natural-seeming code is actually undefined, due to a dangling reference: per the C++ standard, it is equivalent to </p> <pre class="wiki">{ auto &amp;&amp; __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 } } </pre><p> The problem is that the value returned by the subexpression <code>vec | boost::adaptors::reversed</code> is a temporary, so its lifetime ends at the end of the statement containing it, namely the declaration of <code>__range</code>. Thus, <code>__range</code> is left holding a dangling reference to the range it's adapting. </p> <p> 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 <code>std::move</code>) in order to extend its lifetime. </p> gromer@… https://svn.boost.org/trac10/ticket/7630 https://svn.boost.org/trac10/ticket/7630 Report #10142: Range lib type_erased.cpp needs /bigobj option for mcvc and intel-win Mon, 23 Jun 2014 11:37:00 GMT Mon, 25 Aug 2014 21:12:23 GMT <p> 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 </p> <p> # ../../../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 </p> <blockquote> <p> call "C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat" x86_amd64 &gt;nul </p> </blockquote> <p> 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" </p> <p> 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 </p> <p> 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 </p> <p> compilation aborted for adaptor_test/type_erased.cpp (code 4) </p> Elmira Semenova <elmira.a.semenova@…> https://svn.boost.org/trac10/ticket/10142 https://svn.boost.org/trac10/ticket/10142 Report #10332: »indexed« range adaptor's source-breaking change not mentioned in release notes Sat, 09 Aug 2014 20:45:26 GMT Mon, 01 Sep 2014 11:54:45 GMT <p> 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 <code>#if BOOST_VERSION &lt; …</code> around it. See <a class="ext-link" href="http://boost.codepad.org/VE1QSmSz"><span class="icon">​</span>this example</a> (distilled from actual code). </p> <p> Why the ticket? Because the change hasn't been mentioned at all in the <a href="http://www.boost.org/users/history/version_1_56_0.html">release notes</a>. </p> Moritz Bunkus <moritz@…> https://svn.boost.org/trac10/ticket/10332 https://svn.boost.org/trac10/ticket/10332 Report #10336: compilation error in iterator_range and unordered_map Sun, 10 Aug 2014 08:07:32 GMT Sat, 31 Jan 2015 14:52:10 GMT <p> I get a compilation error with vc10, iterator_range and a (const) unordered_map (the beta candidate 2 was still ok I think): </p> <div class="wiki-code"><div class="code"><pre><span class="cp">#include</span> <span class="cpf">&quot;stdafx.h&quot;</span><span class="cp"></span> <span class="cp">#include</span> <span class="cpf">&lt;boost/range/iterator_range.hpp&gt;</span><span class="cp"></span> <span class="cp">#include</span> <span class="cpf">&lt;boost/unordered_map.hpp&gt;</span><span class="cp"></span> <span class="kt">int</span> <span class="nf">_tmain</span><span class="p">(</span><span class="kt">int</span> <span class="cm">/*argc*/</span><span class="p">,</span> <span class="n">_TCHAR</span><span class="o">*</span> <span class="cm">/*argv*/</span><span class="p">[])</span> <span class="p">{</span> <span class="k">typedef</span> <span class="n">boost</span><span class="o">::</span><span class="n">unordered_map</span><span class="o">&lt;</span><span class="kt">int</span><span class="p">,</span> <span class="kt">int</span><span class="o">&gt;</span> <span class="n">Container</span><span class="p">;</span> <span class="k">typedef</span> <span class="n">Container</span><span class="o">::</span><span class="n">const_iterator</span> <span class="n">ContainerIterator</span><span class="p">;</span> <span class="k">typedef</span> <span class="n">boost</span><span class="o">::</span><span class="n">iterator_range</span><span class="o">&lt;</span><span class="n">ContainerIterator</span><span class="o">&gt;</span> <span class="n">ContainerIteratorRange</span><span class="p">;</span> <span class="k">const</span> <span class="n">Container</span> <span class="n">cnt</span><span class="p">;</span> <span class="n">ContainerIteratorRange</span> <span class="n">rng</span><span class="p">(</span><span class="n">cnt</span><span class="p">.</span><span class="n">cbegin</span><span class="p">(),</span> <span class="n">cnt</span><span class="p">.</span><span class="n">cend</span><span class="p">());</span> <span class="k">return</span> <span class="mi">0</span><span class="p">;</span> <span class="p">}</span> </pre></div></div><p> This gives C2248: </p> <p> 'boost::unordered::iterator_detail::c_iterator&lt;Node,<a class="missing wiki">ConstNodePointer</a>&gt;::iterator' </p> <p> cannot access private typedef declared in class </p> <p> etc. </p> <p> Eric: Niebler: </p> <p> 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: </p> <p> github.com/boostorg/range/commit/264017e2a9bdbfcc24517ce05f8ef96df0a8c45b </p> <p> But reverting that doesn't have any effect. It works on Boost 1.55, so this is definitely a regression. </p> <p> Can you please file a bug? Neil, can you take a look? </p> <p> A possible fix: github.com/boostorg/range/pull/19 </p> gast128@… https://svn.boost.org/trac10/ticket/10336 https://svn.boost.org/trac10/ticket/10336 Report #10360: Since 1.56, any_range use static cast of reference instead of implicit conversion Fri, 15 Aug 2014 13:54:28 GMT Fri, 19 Dec 2014 12:47:57 GMT <p> Since 1.56, when dereferencing, any_range tries to use static cast of reference instead of implicit conversion like in 1.55. </p> <p> Here is an example that works with 1.55 but fails to compile with 1.56. </p> <pre class="wiki">#include &lt;boost/range/any_range.hpp&gt; #include &lt;memory&gt; #include &lt;vector&gt; struct A {}; int main() { std::vector&lt;std::shared_ptr&lt;A&gt; &gt; v; boost::any_range&lt;std::shared_ptr&lt;const A&gt;, boost::forward_traversal_tag, std::shared_ptr&lt;const A&gt;, std::ptrdiff_t&gt; r(v); } </pre> vdavid@… https://svn.boost.org/trac10/ticket/10360 https://svn.boost.org/trac10/ticket/10360 Report #10397: compilation error with mfc-iteratior-support: ambiguous symbol Mon, 25 Aug 2014 08:19:11 GMT Sat, 30 Aug 2014 14:33:50 GMT <p> Hi, </p> <p> 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: </p> <p> (MSVC 11 on Windows Server 2008 R2/x64) </p> <p> 25&gt;..\src\libs\boost\boost\boost/range/mfc.hpp(747): error C2872: 'range_const_iterator' : ambiguous symbol 25&gt; could be '..\src\libs\boost\boost\boost/range/const_iterator.hpp(67) : boost::range_const_iterator' 25&gt; or '..\src\libs\boost\boost\boost/range/const_iterator.hpp(40) : boost::range_detail::range_const_iterator' 25&gt; ..\src\libs\boost\boost\boost/range/detail/microsoft.hpp(135) : see reference to class template instantiation 'boost::range_detail_microsoft::customization&lt;Tag&gt;::meta&lt;X&gt;' being compiled 25&gt; with 25&gt; [ 25&gt; Tag=CEbsValueArray::mfc_range_base_type, 25&gt; X=CTypedPtrArray&lt;CObArray,<a class="missing wiki">EbsValue</a> *&gt; 25&gt; ] 25&gt; ..\src\libs\boost\boost\boost/range/begin.hpp(111) : see reference to class template instantiation 'boost::range_detail_microsoft::const_iterator_of&lt;T&gt;' being compiled 25&gt; with 25&gt; [ 25&gt; T=CTypedPtrArray&lt;CObArray,<a class="missing wiki">EbsValue</a> *&gt; 25&gt; ] ... </p> <p> The problem can be resolved by changing the name of </p> <p> boost::range_detail::range_const_iterator </p> <p> to </p> <p> boost::range_detail::range_const_iterator_helper </p> <p> I expect other begin/end adapters to run into the same problem. </p> <p> Tobias </p> Tobias Loew https://svn.boost.org/trac10/ticket/10397 https://svn.boost.org/trac10/ticket/10397 Report #10430: joined_range generates invalid range with recent gcc versions with optimization enabled Sat, 30 Aug 2014 19:40:42 GMT Mon, 01 Sep 2014 11:54:18 GMT <p> 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: </p> <ul><li>gcc 4.3.4 (without C++11 enabled): working at all optimization levels </li><li>gcc 4.7.2 (with C++11 enabled): works without optimizations, failed with -O1 or higher </li><li>gcc 4.8.4 (with C++11 enabled): works without optimizations, failed with -O1 or higher </li><li>clang 3.5.0 (recent build, with C++11 enabled): works at all optimization levels </li></ul><p> The failure was tracked down to a use of boost::range::joined_range (Boost 1.55.0), effectively declared as: </p> <pre class="wiki">boost::range::joined_range&lt;boost::iterator_range&lt;std::vector&lt;char&gt;::iterator, boost::iterator_range&lt;const char*&gt;&gt; </pre><p> 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: </p> <pre class="wiki">g++ -std=c++11 -o join_bug join_bug.cpp </pre><p> works (printing out the expected ASCII values of the joined ranges). Compiled with: </p> <pre class="wiki">g++ -O1 -std=c++11 -o join_bug join_bug.cpp </pre><p> 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. </p> <p> The problem goes away in all tests if the joined_range is declared like so (changing from std::vector&lt;char&gt;::iterator to std::vector&lt;char&gt;::const_iterator): </p> <pre class="wiki">boost::range::joined_range&lt;boost::iterator_range&lt;std::vector&lt;char&gt;::const_iterator, boost::iterator_range&lt;const char*&gt;&gt; </pre><p> 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... </p> Oliver Seiler <oseiler@…> https://svn.boost.org/trac10/ticket/10430 https://svn.boost.org/trac10/ticket/10430 Report #10483: boost::is_sorted docs incorrectly describe predicate Tue, 09 Sep 2014 13:13:34 GMT Mon, 02 Feb 2015 01:20:47 GMT <p> From the documentation </p> <blockquote> <p> For the non-predicate version the return value is true if and only if for each adjacent elements [x,y] the expression x &lt; y is true </p> </blockquote> <p> and similarly for the predicate version. This isn't the case however. </p> <p> From the standard [alg.sorting] </p> <blockquote> <p> 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. </p> </blockquote> <p> So the docs should say </p> <blockquote> <p> the expression y &lt; x is false </p> </blockquote> <p> I get the following with g++'s underlying is_sorted(): </p> <pre class="wiki"> std::vector&lt;int&gt; v{1, 1}; std::cout &lt;&lt; boost::is_sorted(v) &lt;&lt; std::endl; // prints 1 </pre><p> Reference for is_sorted at cplusplus.com [sorry not allowed to post a link] backs this up. </p> charlie@… https://svn.boost.org/trac10/ticket/10483 https://svn.boost.org/trac10/ticket/10483 Report #10493: Since 1.56, any_range with non-reference references can cause UB Thu, 11 Sep 2014 14:04:19 GMT Thu, 08 Mar 2018 08:44:24 GMT <p> This must be related to <a class="assigned ticket" href="https://svn.boost.org/trac10/ticket/10360" title="#10360: Bugs: Since 1.56, any_range use static cast of reference instead of implicit ... (assigned)">#10360</a>. This is a regression since 1.55. </p> <p> When using any_range&lt;T, category, T, ptrdiff_t&gt;, mutable dereference() method returns mutable_reference_type_generator&lt;T&gt;::type, which becomes T&amp;. So dereference() returns a dangling reference to an on-the-fly computed value. </p> <p> See attached test case, which works with 1.55, and fails with -fsanitize=address on Clang 3.5 with 1.56. </p> <pre class="wiki">#include &lt;boost/range/any_range.hpp&gt; #include &lt;boost/range/adaptor/transformed.hpp&gt; #include &lt;cmath&gt; #include &lt;iostream&gt; typedef boost::any_range&lt; std::string, boost::forward_traversal_tag, std::string, std::ptrdiff_t &gt; range_t; std::string f(std::string a) { return a + "!"; } int main() { std::vector&lt;std::string&gt; v = {"a", "b"}; range_t r = v | boost::adaptors::transformed(f); for (auto&amp;&amp; a : r) std::cout &lt;&lt; a &lt;&lt; std::endl; return 0; } </pre> nofitserov@… https://svn.boost.org/trac10/ticket/10493 https://svn.boost.org/trac10/ticket/10493 Report #10515: Range: doc: incorrect return type Thu, 18 Sep 2014 07:51:57 GMT Mon, 02 Feb 2015 01:22:17 GMT <p> This page: <a href="http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/reference/adaptors/reference/filtered.html">http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/reference/adaptors/reference/filtered.html</a> </p> <p> reads: </p> <pre class="wiki">Range Return Type: boost::filtered_range&lt;decltype(rng)&gt; </pre><p> But the code shows that it has two template parameters. </p> <pre class="wiki">namespace boost { namespace range_detail { template&lt; class P, class R &gt; struct filtered_range : </pre><p> Maybe other similar pages lack parameters, I don't know, but they all seem to have a single one documented. </p> akim demaille <akim@…> https://svn.boost.org/trac10/ticket/10515 https://svn.boost.org/trac10/ticket/10515 Report #10865: boost::iterators::transform_iterator<LambdaType> is not default constructible on Clang Thu, 11 Dec 2014 09:49:25 GMT Mon, 02 Feb 2015 01:12:09 GMT <p> 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 <a class="missing ticket">#21787</a> (the bugtracker rejects links here). </p> Balázs Kádár <Balzs.Kdr.ext@…> https://svn.boost.org/trac10/ticket/10865 https://svn.boost.org/trac10/ticket/10865 Report #10988: Range filtered adapter incorrectly requires a ForwardRange Sun, 01 Feb 2015 18:26:23 GMT Sun, 01 Feb 2015 19:06:54 GMT <p> The filtered Range adapter incorrectly requires a <a class="missing wiki">ForwardRange</a>. A <a class="missing wiki">SinglePassRange</a> should be sufficient, since it is for the Boost.Iterator filter_iterator. </p> Neil Groves https://svn.boost.org/trac10/ticket/10988 https://svn.boost.org/trac10/ticket/10988 Report #10989: strided breaks on impure traversal tags Mon, 02 Feb 2015 17:31:03 GMT Mon, 02 Feb 2015 20:19:32 GMT <p> From <a class="ext-link" href="http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed"><span class="icon">​</span>http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed</a> </p> <p> [...]/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&lt;boost::iterators::transform_iterator&lt;TrivialTrafo, __gnu_cxx::__normal_iterator&lt;int*, std::vector&lt;int&gt; &gt;, boost::iterators::use_default, boost::iterators::use_default&gt;, boost::iterators::detail::iterator_category_with_traversal&lt;std::input_iterator_tag, boost::iterators::random_access_traversal_tag&gt; &gt;::strided_iterator(boost::range_detail::strided_iterator&lt;boost::iterators::transform_iterator&lt;TrivialTrafo, __gnu_cxx::__normal_iterator&lt;int*, std::vector&lt;int&gt; &gt;, boost::iterators::use_default, boost::iterators::use_default&gt;, boost::iterators::random_access_traversal_tag&gt;&amp;)’ </p> <blockquote> <p> , m_End(End) </p> </blockquote> <p> 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. </p> anonymous https://svn.boost.org/trac10/ticket/10989 https://svn.boost.org/trac10/ticket/10989 Report #7006: Restricted pointers support. Thu, 21 Jun 2012 10:11:48 GMT Sun, 09 Mar 2014 18:11:10 GMT <p> Trying to form iterator_ranges with restricted pointers causes compiler errors. </p> Domagoj Šarić https://svn.boost.org/trac10/ticket/7006 https://svn.boost.org/trac10/ticket/7006 Report #7742: tie like functionality for ranges Tue, 27 Nov 2012 11:56:41 GMT Mon, 03 Mar 2014 01:50:10 GMT <p> The Graph library uses std::pair to pass ranges and this allows a nice pattern to use old-fashioned for-loops: </p> <blockquote> <p> Graph g; boost::graph_traits&lt;Graph&gt;::vertex_iterator b, e; for(boost::tie(b, e) = vertices(g); b != e; ++b) { </p> </blockquote> <p> </p> <blockquote> <p> } </p> </blockquote> <p> This works without any modifications with pair. </p> <p> 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. </p> philipp.moeller@… https://svn.boost.org/trac10/ticket/7742 https://svn.boost.org/trac10/ticket/7742 Report #12158: boost::size() and friends should use an ADL barrier like boost::begin Tue, 26 Apr 2016 21:35:42 GMT Tue, 26 Apr 2016 21:55:11 GMT <p> boost::begin() and boost::end() are nicely declared in an ADL barrier namespace to avoid conflicts with code like this: </p> <pre class="wiki">using std::begin; auto i = begin(c); </pre><p> <a class="ext-link" href="http://isocpp.org/files/papers/n4280.pdf"><span class="icon">​</span>N4280</a> 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: </p> <pre class="wiki">using std::size; auto s = size(c); </pre><p> They may get an error. For example, if c is a std::vector&lt;boost::shared_ptr&lt;int&gt;&gt; or something, boost::size() will be found by ADL, and since it's no more specific than std::size, the call will be ambiguous. </p> Tavian Barnes <tavianator@…> https://svn.boost.org/trac10/ticket/12158 https://svn.boost.org/trac10/ticket/12158 Report #3483: non-null requirement in ptr_vector::transfer Wed, 23 Sep 2009 09:40:17 GMT Thu, 31 Mar 2011 20:52:16 GMT <p> <a href="http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support">http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support</a> </p> <p> is it possible to remove non-null requirement for <em>from</em> argument in ptr_vector::transfer method? </p> Igor Pavlov <arabesc@…> https://svn.boost.org/trac10/ticket/3483 https://svn.boost.org/trac10/ticket/3483 Report #2836: Request boost::optional<T>::optional_assign_to, optional_move_to, optional_swap Sat, 07 Mar 2009 11:25:11 GMT Sat, 07 Mar 2009 12:46:48 GMT <p> I request the three member functions </p> <p> template&lt; class U &gt; bool boost::optional&lt;T&gt;::optional_assign_to(U&amp; t) const; template&lt; class U &gt; bool boost::optional&lt;T&gt;::optional_move_to(U&amp; t); bool boost::optional&lt;T&gt;::optional_swap(T&amp; t); </p> <p> which, if !*this, return false, and otherwise return true and are equivalent to </p> <p> t=<strong>this; t=</strong>this; and *this may have any value after the move std::swap( t, <strong>this ); </strong></p> aschoedl@… https://svn.boost.org/trac10/ticket/2836 https://svn.boost.org/trac10/ticket/2836 Report #6954: property map 'put' should support move semantics Wed, 30 May 2012 19:12:42 GMT Mon, 27 Jan 2014 23:48:48 GMT <p> 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. </p> wz258@… https://svn.boost.org/trac10/ticket/6954 https://svn.boost.org/trac10/ticket/6954 Report #12033: Boostdep misses some dependent components Mon, 29 Feb 2016 21:33:12 GMT Thu, 03 Mar 2016 17:46:12 GMT <p> 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. </p> <p> 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 </p> edaskel@… https://svn.boost.org/trac10/ticket/12033 https://svn.boost.org/trac10/ticket/12033 Report #1836: bug in serializing wide character strings Thu, 17 Apr 2008 21:12:21 GMT Mon, 29 Nov 2010 20:32:54 GMT <p> 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&lt;Archive&gt; 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. </p> <p> Although the test test_simple_class does test wstrings, it only uses characters 'a'-'z' which does not expose this problem. </p> Jeff Faust <jeff@…> https://svn.boost.org/trac10/ticket/1836 https://svn.boost.org/trac10/ticket/1836 Report #2326: Library does not directly support serializing data of type "foo**" Mon, 15 Sep 2008 03:40:34 GMT Thu, 18 Sep 2008 15:44:22 GMT <p> 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. </p> <p> #include &lt;fstream&gt; </p> <p> #include "boost/archive/text_oarchive.hpp" </p> <p> class foo { </p> <blockquote> <p> friend class boost::serialization::access; </p> </blockquote> <blockquote> <p> template&lt;class archive&gt; </p> </blockquote> <blockquote> <p> void serialize(archive&amp; ar, const unsigned int version) { </p> </blockquote> <blockquote> <blockquote> <p> ar &amp; BOOST_SERIALIZATION_NVP(buff); </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> ar &amp; BOOST_SERIALIZATION_NVP(ptr); </p> </blockquote> </blockquote> <blockquote> <blockquote> <p> } </p> </blockquote> </blockquote> <p> public: </p> <blockquote> <p> foo() : ptr(&amp;buff<a class="changeset" href="https://svn.boost.org/trac10/changeset/3" title="Tweak disclaimer text">[3]</a>) {} </p> </blockquote> <blockquote> <p> int* buff<a class="changeset" href="https://svn.boost.org/trac10/changeset/10" title="*** empty log message *** ">[10]</a>; </p> </blockquote> <blockquote> <p> int<strong> ptr; </strong></p> </blockquote> <blockquote> <p> }; </p> </blockquote> <p> int main() { </p> <blockquote> <p> foo f; </p> </blockquote> <blockquote> <p> std::ofstream serial("serial"); </p> </blockquote> <blockquote> <p> boost::archive::text_oarchive oa(serial); </p> </blockquote> <blockquote> <p> oa &lt;&lt; BOOST_SERIALIZATION_NVP(f); </p> </blockquote> <blockquote> <p> return 0; </p> </blockquote> <blockquote> <p> } </p> </blockquote> anonymous https://svn.boost.org/trac10/ticket/2326 https://svn.boost.org/trac10/ticket/2326 Report #5629: base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator Wed, 22 Jun 2011 13:29:41 GMT Wed, 19 Feb 2014 21:27:41 GMT <p> MSVS 2008 The code: </p> <pre class="wiki">#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&lt;char&gt; my_istream_iterator; typedef std::ostreambuf_iterator&lt;char&gt; my_ostream_iterator; typedef boost::archive::iterators::base64_from_binary&lt; boost::archive::iterators::transform_width&lt; my_istream_iterator, 6, 8&gt; &gt; bin_to_base64; typedef boost::archive::iterators::transform_width&lt; boost::archive::iterators::binary_from_base64&lt; my_istream_iterator &gt;, 8, 6 &gt; 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 &gt;&gt; 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 &gt;&gt; std::noskipws) ), base64_to_bin( my_istream_iterator() ), my_ostream_iterator(ofs) ); } } </pre><p> Result: 1) If the INPUT FILE will be any of ZIP-file format. The result was: </p> <blockquote> <p> a) _DEBUG_ERROR("istreambuf_iterator is not dereferencable"); <em>it can be disabled or ignored b) The encoded file "test.rez" will have one superfluous byte than INPUT FILE </em></p> </blockquote> <p> 2) If the INPUT FILE will any other file (binary or text) all will be OK. </p> nen777w@… https://svn.boost.org/trac10/ticket/5629 https://svn.boost.org/trac10/ticket/5629 Report #5876: Serialization - tracking of non-versioned classes Thu, 08 Sep 2011 09:42:18 GMT Tue, 05 Apr 2016 10:51:57 GMT <p> I quote a case from my workplace. The issue came up for std::vector&lt;int&gt;, but I use a simple struct X to reproduce the problem. See the attached file for detailed instructions. </p> <p> Opened by Yakov Galka 9/8/2011 (Today) 8:31 AM Edit </p> <p> The following code: </p> <pre class="wiki"> 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 </pre><p> Produces different results depending on whether FLAG == 0 or 1, although it's clear that it must not change it's behavior. </p> <p> After some research it happens that the handling of tracking level is broken in boost since at least boost 1.46.1. </p> <p> Assigned to Yakov Galka by Yakov Galka 9/8/2011 (Today) 8:31 AM Notified ######. </p> <p> Edited by Yakov Galka 9/8/2011 (Today) 8:53 AM [Revised 11:44 AM] Edit </p> <p> It happens for objects with implementation level of object_serializable. That is: </p> <pre class="wiki">BOOST_CLASS_IMPLEMENTATION(X, boost::serialization::object_serializable) </pre><p> 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). </p> <p> 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. </p> <p> 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: </p> <p> 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. </p> <p> 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. </p> <p> Edited by Yakov Galka 9/8/2011 (Today) 11:44 AM </p> <p> Revised Yakov Galka's 8:53 AM entry from 9/8/2011 </p> ybungalobill@… https://svn.boost.org/trac10/ticket/5876 https://svn.boost.org/trac10/ticket/5876 Report #6515: Serilaization of std::vector<bool> is broken for optimizing archives Thu, 02 Feb 2012 18:40:38 GMT Sun, 15 Jul 2012 20:35:16 GMT <p> Serializing a vector&lt;bool&gt; causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp): </p> <pre class="wiki">template&lt;class Archive, class U, class Allocator&gt; inline void save( Archive &amp; ar, const std::vector&lt;U, Allocator&gt; &amp;t, const unsigned int /* file_version */, mpl::true_ ){ const collection_size_type count(t.size()); ar &lt;&lt; BOOST_SERIALIZATION_NVP(count); if (!t.empty()) ar &lt;&lt; make_array(detail::get_data(t),t.size()); } </pre><p> While detail::get_data(t) is not specialized for std::vector&lt;bool&gt; (but it should be), and t.size() returns the number of bits stored in the vector, which is probably not what's expected either. </p> <p> I'm encountering this problem with MSVC10, 64bit, Windows7. </p> Hartmut Kaiser https://svn.boost.org/trac10/ticket/6515 https://svn.boost.org/trac10/ticket/6515 Report #12741: Linker error in cross compiling with x86_64-w64-mingw32-g++ Tue, 10 Jan 2017 11:31:22 GMT Fri, 08 Sep 2017 14:53:37 GMT <p> Using </p> <pre class="wiki">using gcc : i686 : i686-w64-mingw32-g++ ; using gcc : x86_64 : x86_64-w64-mingw32-g++ ; </pre><p> in tools/build/src/user-config.jam </p> <p> with x86_64-w64-mingw32-g++ (GCC) 5.3.1 20160211 and calling </p> <pre class="wiki">./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 </pre><p> gives linker errors </p> <pre class="wiki">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&lt;wchar_t&gt;' 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' </pre><p> The 32bit version i686-w64-mingw32-g++ with toolset=gcc-i686 address-model=32 works. </p> zimmermann@… https://svn.boost.org/trac10/ticket/12741 https://svn.boost.org/trac10/ticket/12741 Report #12837: Binary serialization: crash that may allow jump to attacker-controlled address Tue, 14 Feb 2017 18:11:12 GMT Thu, 04 May 2017 16:25:16 GMT <p> Using afl-fuzz on some simple programs that use boost binary and xml serialization, I have found a number of crashes and assertion failures. </p> <p> 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: </p> <pre class="wiki">=&gt; 0x000000000044849c &lt;+524&gt;: mov (%r12),%rax 0x00000000004484a0 &lt;+528&gt;: mov 0x20(%rbp),%r15d 0x00000000004484a4 &lt;+532&gt;: mov %r12,%rdi 0x00000000004484a7 &lt;+535&gt;: callq *0x10(%rax) </pre><p> Notice that the value loaded at instruction &lt;+524&gt; is used to determine the address to call at instruction &lt;+535&gt;. The value of %<a class="changeset" href="https://svn.boost.org/trac10/changeset/12" title="More things getting included from common. ">r12</a> 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. </p> <p> 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): </p> <pre class="wiki">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 </pre><p> The commandline to compile the (non-fuzzing) version of the input test program is: </p> <pre class="wiki">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 </pre><p> The breaking input file is (base-64 encoded): </p> <pre class="wiki">FgAAAAAAAABzZXJpYWxpemF0aW9uOjphcmNoaXZlDwAECAQIAQAAAAAAAAAAAwAAAAAAAAABAAAA AAEAAAD0/wEAAAAAAAAAAAEAAAACAAEAAAACAAAAAgAAAAAA </pre><p> The source for the test harness program (pvec_in.cc) is </p> <pre class="wiki">#include &lt;fstream&gt; #include &lt;vector&gt; #include &lt;boost/shared_ptr.hpp&gt; #include &lt;boost/archive/binary_iarchive.hpp&gt; #include &lt;boost/serialization/nvp.hpp&gt; #include &lt;boost/serialization/shared_ptr.hpp&gt; #include &lt;boost/serialization/vector.hpp&gt; struct boxed_int { boxed_int() : i(0) {} boxed_int(int i) : i(i) {} int i; template&lt;class Archive&gt; void serialize(Archive &amp;ar, unsigned version) { ar &amp; BOOST_SERIALIZATION_NVP(i); } }; typedef boost::shared_ptr&lt;boxed_int&gt; pi; void go(std::istream &amp;is) { std::vector&lt;pi&gt; vv; try { boost::archive::binary_iarchive ia(is); ia &amp; vv; } catch(std::exception &amp;e) {} } int main(int argc, char **argv) { if(argc &gt; 1) { std::ifstream is(argv[1]); go(is); } else { go(std::cin); } return 0; } </pre><p> The test harness program either takes the input file on stdin or the name of the input file as the first positional argument. </p> <p> I can share details about the fuzzing setup if you like. </p> <p> Thank you for taking the time to consider this issue. </p> <p> --Jeff </p> jepler@… https://svn.boost.org/trac10/ticket/12837 https://svn.boost.org/trac10/ticket/12837 Report #12913: Undefined behaviour in serialization library Sun, 19 Mar 2017 18:28:47 GMT Thu, 04 May 2017 16:12:02 GMT <p> Hi Robert, </p> <p> 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: </p> <pre class="wiki">../../../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&lt;boost::archive::xml_oarchive&gt;' 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&lt;boost::archive::xml_oarchive&gt;' SUMMARY: AddressSanitizer: undefined-behavior ../../../boost/archive/detail/interface_oarchive.hpp:47:16 in </pre><p> Which looks like a genuine issue to me. </p> John Maddock https://svn.boost.org/trac10/ticket/12913 https://svn.boost.org/trac10/ticket/12913 Report #13007: When BOOST_BIND_NO_PLACEHOLDERS is defined, framework.ipp seems to be missing an #include Wed, 03 May 2017 18:12:22 GMT Fri, 07 Jul 2017 21:22:41 GMT <p> Like the summary says, I think boost/test/impl/framework.ipp should simply have one additional #include &lt;boost/bind/placeholders.hpp&gt; so it works when BOOST_BIND_NO_PLACEHOLDERS is defined. </p> bspencer@… https://svn.boost.org/trac10/ticket/13007 https://svn.boost.org/trac10/ticket/13007 Report #12240: Documentation for data-driven testing should explictly mention std::tuple Tue, 31 May 2016 14:09:03 GMT Thu, 29 Sep 2016 14:14:53 GMT <p> <code>BOOST_DATA_TEST_CASE()</code> handles ranges of <code>std::tuple</code>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 <code>BOOST_DATA_TEST_CASE()</code> with pre-zipped data rather than always having to use <code>^</code>. </p> <p> However at the moment, this special handling of <code>std::tuple</code> 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 <code>std::tuple</code>s are treated like ranges of other types (ie each tuple is expanded to one variable). </p> <p> Many thanks for your work on this library. </p> Tony Lewis <tonyelewis@…> https://svn.boost.org/trac10/ticket/12240 https://svn.boost.org/trac10/ticket/12240 Report #12902: boost test labels Mon, 13 Mar 2017 18:20:16 GMT Thu, 21 Jun 2018 05:13:35 GMT <p> 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? </p> dimitry https://svn.boost.org/trac10/ticket/12902 https://svn.boost.org/trac10/ticket/12902 Report #8498: cray.jam doesn't build .so files Fri, 26 Apr 2013 04:16:30 GMT Mon, 14 Oct 2013 13:49:35 GMT <p> 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. </p> alan@… https://svn.boost.org/trac10/ticket/8498 https://svn.boost.org/trac10/ticket/8498 Report #9704: b2: Compiler flavour has no flexibility for cross-compiling projects. Mon, 24 Feb 2014 20:39:19 GMT Fri, 04 Apr 2014 22:13:25 GMT <p> Hi, </p> <p> I've been trying hard, but it is annoying, didn't find it elsewhere and it could really be improved. </p> <p> I am building my project (i.e. all of my project tree) </p> <blockquote> <p> on 2 platforms: </p> </blockquote> <ul><li>Windows, </li><li>Linux, </li></ul><p> for 3 different platforms: </p> <ul><li>Windows </li><li>Linux IA32 </li><li>Linux ARM HF </li></ul><p> 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. </p> <p> I have managed to define it somehow, i.e. in my project_config.jam (@ home dir): </p> <pre class="wiki">if [ os.name ] = NT { using gcc : : : &lt;cxxflags&gt;-std=c++11 &lt;cxxflags&gt;"-include cmath" &lt;cxxflags&gt;-Wdeprecated-declarations ; using gcc : armhf : arm-linux-gnueabihf-g++.exe : &lt;cxxflags&gt;-std=c++11 &lt;cxxflags&gt;"-include cmath" &lt;cxxflags&gt;-Wdeprecated-declarations ; } if [ os.name ] = LINUX { using gcc : : : &lt;cxxflags&gt;-std=c++11 &lt;cxxflags&gt;"-include cmath" ; using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ : &lt;cxxflags&gt;-std=c++11 &lt;cxxflags&gt;"-include cmath" &lt;cxxflags&gt;-Wdeprecated-declarations ; } </pre><p> 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: </p> <pre class="wiki">install copy_binaries_to_release : target_names.. : &lt;target-os&gt;linux:&lt;toolset-gcc:version&gt;4.7:&lt;location&gt;../../release/ &lt;target-os&gt;windows:&lt;toolset&gt;gcc-4.7.2-mingw:&lt;location&gt;../../release/ &lt;toolset-gcc:version&gt;armhf:&lt;location&gt;../../release_armhf/ &lt;toolset&gt;gcc-mingw-armhf:&lt;location&gt;../../release/ ; </pre><p> Is there a better way of doing it? </p> <p> 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). </p> <p> Problems: </p> <ol><li>Different toolset names when building on different OSes (and yes, I did try to specify a default flavor, but see Problem 2). </li></ol><table class="wiki"> <tr><td style="text-align: center"> </td><td> command </td><td> toolset </td><td> flavor </td></tr><tr><td> gcc XA32(linux) </td><td> b2 </td><td> gcc </td><td> 4.7 </td></tr><tr><td> gcc XA32(win) </td><td> b2 </td><td> gcc-4.7.2-mingw </td><td> ? </td></tr><tr><td> <strong>gcc armhf(linux)</strong> </td><td> <strong>b2 --toolset=gcc-armhf</strong> </td><td> <strong>gcc</strong> </td><td> <strong>armhf</strong> </td></tr><tr><td> gcc armhf(win) </td><td> b2 --toolset=gcc-armhf target-os=linux </td><td> gcc-mingw-armhf </td><td> ? </td></tr></table> <p> 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. </p> <p> 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). </p> <ol start="2"><li>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. </li></ol><p> Couldn't it leave it alone, and use flavor that was explicitly specified? </p> <p> I really wish that I could specify above: </p> <pre class="wiki">using gcc : 4.7 : &lt;my-path-to-gcc47&gt; ... ; using gcc : armhf : &lt;my-path-to-gcc47 arm hf&gt; ... ; </pre><p> 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 </p> <pre class="wiki">b2 --toolset=gcc-armhf </pre><p> with g++ (and having to hack/create symlinks to match this etc.) - </p> <p> It should just accept what I specify, and use it 'as-is' (and if someone does something stupid - let them fail and fix it). </p> <p> There could also be a support for something like: </p> <pre class="wiki">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.. : &lt;toolset&gt;gcc,&lt;flavor&gt;4.7:&lt;location&gt;../../release &lt;toolset&gt;gcc,&lt;flavor&gt;armhf:&lt;location&gt;../../release_$(gcc_flavor) # or even to: &lt;toolset&gt;gcc:&lt;location&gt;../../release_$(gcc_flavor) ; </pre><p> With a bit of guidance / advice from someone, who knows the build system well - I'm happy to help with implementing the above. </p> <p> Thanks, LUkasz. </p> <p> (BTW: what is the best component for build system / tools?) </p> lukasz.forynski@… https://svn.boost.org/trac10/ticket/9704 https://svn.boost.org/trac10/ticket/9704 Report #6026: phoenix block statement tries to copy objects instead of references Fri, 14 Oct 2011 16:17:15 GMT Mon, 09 May 2016 15:02:25 GMT <p> Let's use a simplest class, that can't be copied: </p> <pre class="wiki">class A { A() {} A(const A&amp;); public: static A* construct() { return new A(); } const A&amp; operator&lt;&lt;(const char *p) const { return *this; } }; A *pa = A::construct(); A &amp;a = *pa; </pre><p> The code which use this object one time normally works: </p> <pre class="wiki">(boost::phoenix::ref(a) &lt;&lt; boost::phoenix::placeholders::_1)("aaa"); </pre><p> But when I try to use this object two times, I get an error: </p> <pre class="wiki">( boost::phoenix::ref(a) &lt;&lt; boost::phoenix::placeholders::_1 ,boost::phoenix::ref(a) &lt;&lt; boost::phoenix::placeholders::_1 )("aaa"); </pre><p> Result: 'A::A' : cannot access private member declared in class 'A' </p> <p> Expecting: pass compilation and invoke "A::operator&lt;&lt;" two times. </p> <p> Note: preprocessing directive "BOOST_SPIRIT_USE_PHOENIX_V3" was defined. </p> armagvvg@… https://svn.boost.org/trac10/ticket/6026 https://svn.boost.org/trac10/ticket/6026 Report #6911: [Phoenix V3] Add tr1_result_of specialization Thu, 17 May 2012 15:01:15 GMT Fri, 19 Jan 2018 19:51:45 GMT <p> To make <code>result_of</code> and <code>tr1_result_of</code> equivalent, we have to add specialization of <code>tr1_result_of</code>. (Boost.Phoenix V3 already has specialization of <code>result_of</code>.) </p> <p> Also, it would be nice to avoid specialization of <code>result_of</code>, when we use decltype-based <code>result_of</code>. (As for <code>tr1_result_of</code>, it should be specialized even when decltype-based <code>result_of</code> is used.) </p> <p> So, instead of </p> <pre class="wiki">template &lt;...&gt; struct result_of&lt;F()&gt; { typedef XXXX type; }; </pre><p> we should write </p> <pre class="wiki">#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE) template &lt;...&gt; struct result_of&lt;F()&gt; { typedef XXXX type; }; #endif template &lt;...&gt; struct tr1_result_of&lt;F()&gt; { typedef XXXX type; }; </pre><p> A quick grep said the following files specialize <code>result_of</code>. </p> <ul><li>phoenix/core/actor.hpp </li><li>phoenix/function/function.hpp </li></ul> Michel Morin https://svn.boost.org/trac10/ticket/6911 https://svn.boost.org/trac10/ticket/6911 Report #5558: Phoenix bind doesn't support bind<type> construct Mon, 23 May 2011 15:37:50 GMT Mon, 09 May 2016 14:07:41 GMT <p> boost::bind uses bind&lt;type&gt; 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. </p> <p> I'm not so much concerned with the bind&lt;type&gt; 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? </p> <p> Using boost::bind -- </p> <blockquote> <p> boost::bind&lt;int&gt;( &amp;printf, "%d ", _1 )(42); </p> </blockquote> <p> Using phoenix::bind -- </p> <blockquote> <p> phx::bind( &amp;printf, "%d ", arg1 )(42); </p> </blockquote> <p> results in compilation error. </p> Michael Caisse https://svn.boost.org/trac10/ticket/5558 https://svn.boost.org/trac10/ticket/5558 Report #3450: [fix in git] Bug into boost::python::stl_input_iterator Tue, 15 Sep 2009 07:53:33 GMT Mon, 21 Sep 2009 07:59:44 GMT <p> I noticed that if you try to traverse more than once the range (begin,end) obtained with the <code>stl_input_iterator</code>, 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 <code>std::distance</code> function.<br /> If you build with <code>-DWORK_AROUND</code> the problem disappears, but I need to call <code>std::distance</code>, because it is the original class that calls it (and I prefer not to modify it simply for building a python extension). </p> micdestefano@… https://svn.boost.org/trac10/ticket/3450 https://svn.boost.org/trac10/ticket/3450 Report #3673: boost python and weak_ptr from a shared_ptr argument Thu, 26 Nov 2009 07:22:57 GMT Tue, 11 Jun 2013 18:44:38 GMT <p> 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 </p> troy d. straszheim https://svn.boost.org/trac10/ticket/3673 https://svn.boost.org/trac10/ticket/3673 Report #2838: MPI Python bindings not installed correctly Mon, 09 Mar 2009 09:22:55 GMT Sat, 03 Nov 2012 23:51:39 GMT <p> I've successfully built and installed boost.MPI and the Python bindings in my home dir. </p> <p> 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 </p> <p> <a href="http://www.boost.org/doc/libs/1_38_0/doc/html/mpi/python.html">http://www.boost.org/doc/libs/1_38_0/doc/html/mpi/python.html</a> </p> <p> I think that the Python modules should go to a sudirectory "boost" in the lib path, or it should be fixed in the documentation. </p> <p> Otherwise, the boost.mpi Python bindings are gorgeous! </p> lenzo@… https://svn.boost.org/trac10/ticket/2838 https://svn.boost.org/trac10/ticket/2838 Report #4657: Boost.MPI Compile failure with Python 3 Sat, 18 Sep 2010 18:04:50 GMT Tue, 03 Dec 2013 09:18:26 GMT <p> 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 <a class="ext-link" href="http://lists.boost.org/Archives/boost/2010/09/170659.php"><span class="icon">​</span>http://lists.boost.org/Archives/boost/2010/09/170659.php</a> for the full error output). </p> <p> This failure was discussed in Debian (<a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595786"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595786</a>) and Andreas Kloeckner provided a patch. See attached. </p> <p> -Steve </p> <blockquote> <p> "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" </p> </blockquote> <p> 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, </p> <blockquote> <p> 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: </p> </blockquote> <p> ...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... </p> <p> and </p> <blockquote> <p> "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" </p> </blockquote> <p> 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<strong>’ to ‘wchar_t</strong>’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t<strong>)’ ...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... </strong></p> smr@… https://svn.boost.org/trac10/ticket/4657 https://svn.boost.org/trac10/ticket/4657 Report #2557: iostreams filtering_stream w/ gzip infinite loop when writing to a full drive Mon, 01 Dec 2008 19:27:03 GMT Wed, 12 Jul 2017 12:45:47 GMT <p> 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. </p> <p> 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. </p> Tomasz Śniatowski <kailoran@…> https://svn.boost.org/trac10/ticket/2557 https://svn.boost.org/trac10/ticket/2557 Report #7319: Take care of c++std-lib-32966 issue Sun, 02 Sep 2012 08:32:23 GMT Sun, 02 Sep 2012 08:41:34 GMT <p> Take care of the issue raised by Howard Hinnant in </p> <p> [c++std-lib-32966] Public service announcement concerning ~condition_variable_any() </p> <p> "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 <a class="ext-link" href="http://www.unix.org/online.html"><span class="icon">​</span>http://www.unix.org/online.html</a> under the specification for pthread_cond_destroy. </p> <p> This subtlety is reflected in the Requires clause for the destructor of both condition_variable and condition_variable_any: </p> <blockquote class="citation"> <p> 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 ] </p> </blockquote> <p> To be *perfectly* clear, the following is ok: </p> <pre class="wiki"> 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 </pre><p> " </p> viboes https://svn.boost.org/trac10/ticket/7319 https://svn.boost.org/trac10/ticket/7319 Report #7912: boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG Mon, 21 Jan 2013 11:25:12 GMT Sun, 09 Jun 2013 20:12:37 GMT <p> As I understood from the trac ticket <a class="ext-link" href="https://svn.boost.org/trac/boost/ticket/7089"><span class="icon">​</span>https://svn.boost.org/trac/boost/ticket/7089</a> 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. </p> Viatcheslav.Sysoltsev@… https://svn.boost.org/trac10/ticket/7912 https://svn.boost.org/trac10/ticket/7912 Report #8600: wait_for_any hangs, if called with multiple copies of shared_future referencing same task Tue, 21 May 2013 11:50:16 GMT Tue, 04 Jun 2013 06:13:38 GMT <p> The following small test program shows the problem: </p> <pre class="wiki">#include &lt;iostream&gt; #include &lt;boost/thread.hpp&gt; int calculate_the_answer_to_life_the_universe_and_everything() { return 42; } int main(int argc, char* argv[]) { boost::packaged_task&lt;int&gt; pt(calculate_the_answer_to_life_the_universe_and_everything); boost::shared_future&lt;int&gt; fi1 = boost::shared_future&lt;int&gt;(pt.get_future()); boost::shared_future&lt;int&gt; fi2 = fi1; boost::thread task(boost::move(pt)); // launch task on a thread boost::wait_for_any(fi1, fi2); std::cout &lt;&lt; "Wait for any returned\n"; return (0); } </pre><p> 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. </p> Martin Apel <martin.apel@…> https://svn.boost.org/trac10/ticket/8600 https://svn.boost.org/trac10/ticket/8600 Report #11091: notify_all_at_thread_exit - ThreadSanitizer: data race Mon, 09 Mar 2015 23:43:03 GMT Mon, 09 Mar 2015 23:43:18 GMT <pre class="wiki"> 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*) &lt;null&gt; (libboost_thread.so.1.58.0+0x00000002567a) Previous write of size 8 at 0x7fd7f9795c48 by main thread: #0 &lt;null&gt; &lt;null&gt; (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() &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main &lt;null&gt; (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&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000318e5) #1 boost::(anonymous namespace)::thread_proxy(void*) &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7d4c0000de58 by main thread (mutexes: write M24): #0 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::swap(boost::shared_ptr&lt;boost::detail::thread_data_base&gt;&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x000000031796) #1 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::operator=(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x00000003142d) #2 boost::thread::start_thread_noexcept() &lt;null&gt; (libboost_thread.so.1.58.0+0x000000025579) #3 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #4 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #5 main &lt;null&gt; (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&lt;void (*)()&gt;* boost::detail::heap_new&lt;boost::detail::thread_data&lt;void (*)()&gt;, void (*)()&gt;(void (*&amp;&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6acb) #2 boost::thread::make_thread_info(void (*)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3a87) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f82) #4 main &lt;null&gt; (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() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c27d7) #2 __cxx_global_var_init10 &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004439cc) #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp &lt;null&gt; (notify_all_at_thread_exit_p+0x000000443a43) #4 __libc_csu_init &lt;null&gt; (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() &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) ================== ================== WARNING: ThreadSanitizer: data race (pid=14082) Write of size 8 at 0x7fd7f9795c38 by thread T1: #0 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000318f9) #1 boost::(anonymous namespace)::thread_proxy(void*) &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7fd7f9795c38 by main thread: #0 &lt;null&gt; &lt;null&gt; (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() &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) ================== ================== 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&amp;) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c7696) #1 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x000000031929) #2 boost::(anonymous namespace)::thread_proxy(void*) &lt;null&gt; (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&amp;) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c71cb) #1 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::swap(boost::shared_ptr&lt;boost::detail::thread_data_base&gt;&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000317d6) #2 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::operator=(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x00000003142d) #3 boost::thread::start_thread_noexcept() &lt;null&gt; (libboost_thread.so.1.58.0+0x000000025579) #4 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #5 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #6 main &lt;null&gt; (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&lt;void (*)()&gt;* boost::detail::heap_new&lt;boost::detail::thread_data&lt;void (*)()&gt;, void (*)()&gt;(void (*&amp;&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6acb) #2 boost::thread::make_thread_info(void (*)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3a87) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f82) #4 main &lt;null&gt; (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() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c27d7) #2 __cxx_global_var_init10 &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004439cc) #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp &lt;null&gt; (notify_all_at_thread_exit_p+0x000000443a43) #4 __libc_csu_init &lt;null&gt; (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() &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&amp;) ================== ================== 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&amp;) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c76aa) #1 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x000000031929) #2 boost::(anonymous namespace)::thread_proxy(void*) &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7fd7f9795c40 by main thread: #0 &lt;null&gt; &lt;null&gt; (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() &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&amp;) ================== ================== 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*) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c77cc) #2 boost::detail::sp_counted_base::add_ref_copy() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c7749) #3 boost::detail::shared_count::shared_count(boost::detail::shared_count const&amp;) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c76e6) #4 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr(boost::shared_ptr&lt;boost::detail::thread_data_base&gt; const&amp;) &lt;null&gt; (libboost_thread.so.1.58.0+0x000000031929) #5 boost::(anonymous namespace)::thread_proxy(void*) &lt;null&gt; (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&lt;boost::detail::thread_data&lt;void (*)()&gt; &gt;(boost::detail::thread_data&lt;void (*)()&gt;*) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6f67) #2 void boost::detail::sp_pointer_construct&lt;boost::detail::thread_data_base, boost::detail::thread_data&lt;void (*)()&gt; &gt;(boost::shared_ptr&lt;boost::detail::thread_data_base&gt;*, boost::detail::thread_data&lt;void (*)()&gt;*, boost::detail::shared_count&amp;) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6dd0) #3 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr&lt;boost::detail::thread_data&lt;void (*)()&gt; &gt;(boost::detail::thread_data&lt;void (*)()&gt;*) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6c7b) #4 boost::thread::make_thread_info(void (*)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3a93) #5 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f82) #6 main &lt;null&gt; (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&lt;boost::detail::thread_data&lt;void (*)()&gt; &gt;(boost::detail::thread_data&lt;void (*)()&gt;*) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6f67) #2 void boost::detail::sp_pointer_construct&lt;boost::detail::thread_data_base, boost::detail::thread_data&lt;void (*)()&gt; &gt;(boost::shared_ptr&lt;boost::detail::thread_data_base&gt;*, boost::detail::thread_data&lt;void (*)()&gt;*, boost::detail::shared_count&amp;) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6dd0) #3 boost::shared_ptr&lt;boost::detail::thread_data_base&gt;::shared_ptr&lt;boost::detail::thread_data&lt;void (*)()&gt; &gt;(boost::detail::thread_data&lt;void (*)()&gt;*) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c6c7b) #4 boost::thread::make_thread_info(void (*)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3a93) #5 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f82) #6 main &lt;null&gt; (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() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c27d7) #2 __cxx_global_var_init10 &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004439cc) #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp &lt;null&gt; (notify_all_at_thread_exit_p+0x000000443a43) #4 __libc_csu_init &lt;null&gt; (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() &lt;null&gt; (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread&lt;void (&amp;)()&gt;(void (&amp;)()) &lt;null&gt; (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main &lt;null&gt; (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 </pre> viboes https://svn.boost.org/trac10/ticket/11091 https://svn.boost.org/trac10/ticket/11091 Report #11499: windows - exception lock_error while intensive locking/unlocking of shared_mutex on many threads Sat, 25 Jul 2015 23:07:06 GMT Mon, 15 Aug 2016 17:59:25 GMT <pre class="wiki">#include "stdafx.h" #include &lt;boost/thread/shared_mutex.hpp&gt; #include &lt;thread&gt; #include &lt;mutex&gt; #include &lt;shared_mutex&gt; #include &lt;atomic&gt; #include &lt;vector&gt; using MutexT = boost::shared_mutex; using ReaderLockT = std::lock_guard&lt;MutexT&gt;; using WriterLockT = std::shared_lock&lt;MutexT&gt;; MutexT gMutex; std::atomic&lt;bool&gt; running = true; long reads = 0; void read() { while (running) { ReaderLockT lock(gMutex); std::this_thread::yield(); ++reads; } } int main() { using namespace std; vector&lt;thread&gt; threads; for (int i = 0; i &lt; 256; ++i) { threads.emplace_back(thread(read)); } string str; getline(std::cin, str); running = false; for (auto&amp; thread : threads) { thread.join(); } return 0; } </pre> andrew maclean <agm@…> https://svn.boost.org/trac10/ticket/11499 https://svn.boost.org/trac10/ticket/11499 Report #11550: Solaris - boost::call_once issues Tue, 18 Aug 2015 10:46:34 GMT Wed, 23 Sep 2015 22:23:06 GMT <p> I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I </p> <blockquote> <p> get the following error messages: </p> </blockquote> <pre class="wiki">"libs/thread/src/pthread/thread.cpp", line 144: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "libs/thread/src/pthread/thread.cpp", line 150: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "libs/context/src/posix/stack_traits.cpp", line 58: Error: Overloading ambiguity between "boost::call_once&lt;void(&amp;)(unsigned long*), unsigned long*&gt;(boost::once_flag&amp;, void(&amp;)(unsigned long*), unsigned long*&amp;&amp;)" and "boost::call_once&lt;void(*)(unsigned long*), unsigned long*&gt;(boost::once_flag&amp;, void(*)(unsigned long*), unsigned long*)". "libs/context/src/posix/stack_traits.cpp", line 66: Error: Overloading ambiguity between "boost::call_once&lt;void(&amp;)(rlimit*), rlimit*&gt;(boost::once_flag&amp;, void(&amp;)(rlimit*), rlimit*&amp;&amp;)" and "boost::call_once&lt;void(*)(rlimit*), rlimit*&gt;(boost::once_flag&amp;, void(*)(rlimit*), rlimit*)". "libs/coroutine/src/posix/stack_traits.cpp", line 56: Error: Overloading ambiguity between "boost::call_once&lt;void(&amp;)(unsigned long*), unsigned long*&gt;(boost::once_flag&amp;, void(&amp;)(unsigned long*), unsigned long*&amp;&amp;)" and "boost::call_once&lt;void(*)(unsigned long*), unsigned long*&gt;(boost::once_flag&amp;, void(*)(unsigned long*), unsigned long*)". "libs/coroutine/src/posix/stack_traits.cpp", line 64: Error: Overloading ambiguity between "boost::call_once&lt;void(&amp;)(rlimit*), rlimit*&gt;(boost::once_flag&amp;, void(&amp;)(rlimit*), rlimit*&amp;&amp;)" and "boost::call_once&lt;void(*)(rlimit*), rlimit*&gt;(boost::once_flag&amp;, void(*)(rlimit*), rlimit*)". "./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(*)()&amp;&gt;(boost::once_flag&amp;, void(*)()&amp;)". "./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(*)()&amp;&gt;(boost::once_flag&amp;, void(*)()&amp;)". "./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(*)()&amp;&gt;(boost::once_flag&amp;, void(*)()&amp;)". "./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(*)()&amp;&gt;(boost::once_flag&amp;, void(*)()&amp;)". "./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". "./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(*)()&amp;&gt;(boost::once_flag&amp;, void(*)()&amp;)". "./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once&lt;void(*)()&gt;(boost::once_flag&amp;, void(*)())" and "boost::call_once&lt;void(&amp;)()&gt;(boost::once_flag&amp;, void(&amp;)())". </pre><p> I'm not 100% sure whether these are compiler issues or Boost compiler configuration issues thus I decided to raise this ticket. </p> lcarreon@… https://svn.boost.org/trac10/ticket/11550 https://svn.boost.org/trac10/ticket/11550 Report #12104: windows - Visual Studio 2015 Update 2 RC gives out warning C4191 in thread_primitive.hpp Wed, 30 Mar 2016 22:21:21 GMT Sat, 16 Sep 2017 16:48:44 GMT <pre class="wiki">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' </pre><p> Calling this function through the result pointer may cause your program to fail </p> Shane Mathews (oneZero Financial Systems) <smathews@…> https://svn.boost.org/trac10/ticket/12104 https://svn.boost.org/trac10/ticket/12104 Report #12773: WINDOWS- Boost thread 1.63.0 strict aliasing warnings Thu, 19 Jan 2017 13:34:42 GMT Tue, 14 Nov 2017 20:54:51 GMT <p> I'm cross-compiling boost on Linux, having 32-bit mingw64 as a target. </p> <p> I'm still seeing strict aliasing complaints on boost 1.63.0 thread/win32/shared_mutex.hpp. </p> <p> 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. </p> alexandre.nunes@… https://svn.boost.org/trac10/ticket/12773 https://svn.boost.org/trac10/ticket/12773 Report #12795: thread library - thread_specific_ptr documentation gives obsolete recomendation Fri, 27 Jan 2017 09:37:42 GMT Tue, 14 Nov 2017 20:43:42 GMT <p> thread_specific_ptr documentation says </p> <p> <em>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.</em> </p> <p> Now as we have portable <strong>thread_local</strong> in current compilers, it should be prefered to use <strong>thread_local</strong>, since thread_specific_ptr has known performance limitation. </p> Oleksandr Guteniev <gutenev@…> https://svn.boost.org/trac10/ticket/12795 https://svn.boost.org/trac10/ticket/12795 Report #5947: Use CLOCK_PROCESS_CPUTIME_ID on platform providing them Tue, 27 Sep 2011 11:30:41 GMT Sun, 03 Jun 2012 14:11:46 GMT <p> The posix implementation of process real cpu clock uses the times() function. The resolution is better if we use </p> <blockquote> <p> ::clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &amp;ts ); </p> </blockquote> <p> on platforms for which the CLOCK_PROCESS_CPUTIME_ID is supported. </p> viboes https://svn.boost.org/trac10/ticket/5947 https://svn.boost.org/trac10/ticket/5947 Report #7333: Provide User-defined Literals for chrono durations on compilers supporting them Thu, 06 Sep 2012 04:13:35 GMT Sat, 08 Sep 2012 06:46:29 GMT <p> boost::chrono::duration suffixes h, min, s, ms, us, ns in namespace boost::suffixes::chrono </p> viboes https://svn.boost.org/trac10/ticket/7333 https://svn.boost.org/trac10/ticket/7333 Report #7586: Add a testable_mutex Sun, 28 Oct 2012 19:22:13 GMT Fri, 05 Sep 2014 06:11:32 GMT <p> Based on Associate Mutexes with Data to Prevent Races, By Herb Sutter, May 13, 2010 - <a class="ext-link" href="http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3"><span class="icon">​</span>http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3</a> </p> <p> "Make our mutex testable if it isn't already. </p> <p> Many mutex services (including boost::mutex) don't provide a way to ask, "Do I already hold a lock on this mutex?" </p> <p> Sometimes it is needed to know if a method like is_held to be available. </p> <p> 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. </p> <p> 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." </p> viboes https://svn.boost.org/trac10/ticket/7586 https://svn.boost.org/trac10/ticket/7586 Report #7589: Add polymorphic lockables Sun, 28 Oct 2012 19:43:12 GMT Fri, 05 Sep 2014 06:11:43 GMT <p> 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. </p> <p> 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. </p> viboes https://svn.boost.org/trac10/ticket/7589 https://svn.boost.org/trac10/ticket/7589 Report #7595: Implement interruptible threads on top of non-interruptible threads Sun, 28 Oct 2012 20:05:07 GMT Sun, 28 Oct 2012 20:06:01 GMT <p> 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. </p> <p> See <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/7594" title="#7594: Feature Requests: Allow to disable thread interruptions (closed: fixed)">#7594</a> Allow to disallow thread interruptions </p> viboes https://svn.boost.org/trac10/ticket/7595 https://svn.boost.org/trac10/ticket/7595 Report #7629: Implement the algorithm deadlock detection "lockdep" Fri, 02 Nov 2012 16:24:53 GMT Sun, 04 Nov 2012 00:28:06 GMT <p> Implement the algorithm deadlock detection "lockdep" (<a class="ext-link" href="http://ceph.com/dev-notes/lockdep-for-pthreads/"><span class="icon">​</span>http://ceph.com/dev-notes/lockdep-for-pthreads/</a>) </p> anonymous https://svn.boost.org/trac10/ticket/7629 https://svn.boost.org/trac10/ticket/7629 Report #8094: hierarchical_mutex for lock hierarchies (to avoid deadlocks) Sun, 17 Feb 2013 21:24:36 GMT Sun, 26 Oct 2014 20:41:49 GMT <p> 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 <a class="changeset" href="https://svn.boost.org/trac10/changeset/1" title="Import core sources for SVNmanger 0.38 ">[1]</a>. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing. </p> <p> 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. </p> <p> <a class="changeset" href="https://svn.boost.org/trac10/changeset/1" title="Import core sources for SVNmanger 0.38 ">[1]</a> <a class="ext-link" href="http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163"><span class="icon">​</span>http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163</a> </p> Fredrik Orderud <forderud@…> https://svn.boost.org/trac10/ticket/8094 https://svn.boost.org/trac10/ticket/8094 Report #8273: Add externally locked streams Mon, 11 Mar 2013 07:21:19 GMT Fri, 05 Sep 2014 06:11:53 GMT <p> Based on N3354: C++ Stream Mutexes <a class="ext-link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3354.html"><span class="icon">​</span>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3354.html</a> 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. </p> <p> This will be useful to take in account coherency when working with cout and cin. </p> viboes https://svn.boost.org/trac10/ticket/8273 https://svn.boost.org/trac10/ticket/8273 Report #8514: Async: Add a thread_pool executor with work stealing. Sun, 28 Apr 2013 20:57:06 GMT Tue, 30 Apr 2013 22:49:57 GMT <p> See <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/8513" title="#8513: Feature Requests: Async: Add a basic thread_pool executor. (closed: fixed)">#8513</a> for the basic thread_pool interface </p> viboes https://svn.boost.org/trac10/ticket/8514 https://svn.boost.org/trac10/ticket/8514 Report #8517: Async: Add a variadic shared_future::then Sun, 28 Apr 2013 21:07:05 GMT Tue, 28 May 2013 19:09:38 GMT <pre class="wiki">template&lt;typename S, typename ...F&gt; shared_future&lt;tuple&lt;typename boost::result_of&lt;F(shared_future&amp;)&gt;::type...&gt; future::then(S&amp;, F&amp;&amp; func ...); </pre> viboes https://svn.boost.org/trac10/ticket/8517 https://svn.boost.org/trac10/ticket/8517 Report #9588: Add a parallel_invoke algorithm. Sat, 18 Jan 2014 10:53:12 GMT Tue, 21 Jan 2014 18:03:46 GMT <p> Base on <a class="ext-link" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf"><span class="icon">​</span>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf</a> and TBB Intel library add a parallel_invoke algorithm. </p> <p> The main difference is that the algorithm could take an Executor as parameter. </p> viboes https://svn.boost.org/trac10/ticket/9588 https://svn.boost.org/trac10/ticket/9588 Report #9589: Add a parallel_sort algorithm. Sat, 18 Jan 2014 10:53:57 GMT Tue, 21 Jan 2014 18:03:55 GMT <p> Base on <a class="ext-link" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf"><span class="icon">​</span>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf</a> and TBB Intel library add a parallel_sort algorithm. </p> <p> The main difference is that the algorithm could take an Executor as parameter. </p> viboes https://svn.boost.org/trac10/ticket/9589 https://svn.boost.org/trac10/ticket/9589 Report #9590: Add a parallel_reduce algorithm. Sat, 18 Jan 2014 10:55:43 GMT Tue, 21 Jan 2014 18:04:06 GMT <p> Base on <a class="ext-link" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf"><span class="icon">​</span>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf</a> and TBB Intel library add a parallel_reduce algorithm. </p> <p> The main difference is that the algorithm could take an Executor as parameter. </p> viboes https://svn.boost.org/trac10/ticket/9590 https://svn.boost.org/trac10/ticket/9590 Report #9591: Add a parallel_for algorithm. Sat, 18 Jan 2014 10:58:07 GMT Wed, 22 Jan 2014 12:07:39 GMT <p> Base on <a class="ext-link" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf"><span class="icon">​</span>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf</a> and TBB Intel library add a parallel_for algorithm. </p> <p> The main difference is that the algorithm could take an Executor as parameter. </p> viboes https://svn.boost.org/trac10/ticket/9591 https://svn.boost.org/trac10/ticket/9591 Report #9592: Add a parallel_for_each algorithm Sat, 18 Jan 2014 11:01:52 GMT Tue, 21 Jan 2014 18:04:27 GMT <p> Base on <a class="ext-link" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf"><span class="icon">​</span>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf</a> and TBB Intel library add a parallel_for_each algorithm. </p> <p> The main difference is that the algorithm could take an Executor as parameter. </p> viboes https://svn.boost.org/trac10/ticket/9592 https://svn.boost.org/trac10/ticket/9592 Report #9599: Add a parallel_transform algorithm Wed, 22 Jan 2014 12:03:31 GMT Wed, 22 Jan 2014 12:06:12 GMT <p> Base on <a class="ext-link" href="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf"><span class="icon">​</span>http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf</a> and TBB Intel library add a parallel_transform algorithm. </p> <p> The main difference is that the algorithm could take an Executor as parameter. </p> viboes https://svn.boost.org/trac10/ticket/9599 https://svn.boost.org/trac10/ticket/9599 Report #10299: Add queue iterators Sat, 02 Aug 2014 15:10:58 GMT Sat, 02 Aug 2014 15:11:12 GMT <p> As for <a class="ext-link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators"><span class="icon">​</span>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators</a> add queue iterators. </p> viboes https://svn.boost.org/trac10/ticket/10299 https://svn.boost.org/trac10/ticket/10299 Report #10301: Add shared_queue_front and shared_queue_back Sat, 02 Aug 2014 15:20:52 GMT Sat, 02 Aug 2014 15:41:52 GMT <p> Based on <a class="ext-link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#Managed"><span class="icon">​</span>http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#Managed</a> add shared_queue_front and shared_queue_back. </p> viboes https://svn.boost.org/trac10/ticket/10301 https://svn.boost.org/trac10/ticket/10301 Report #10316: Thread: add subscription operator if the value provide it. Wed, 06 Aug 2014 08:51:17 GMT Mon, 29 Sep 2014 08:19:58 GMT <p> I would like to be able to do </p> <pre class="wiki"> typedef boost::synchronized_value&lt; boost::container::flat_map&lt;int, int&gt; &gt; ValueIndex; ValueIndex index; index[0] = 1; </pre><p> and would expect that last line to be equivalent to </p> <pre class="wiki"> auto locked_index = index.synchronize(); (*locked_index)[0] = 1; </pre><p> </p> <p> I'm not totally sure it's possible to do but it would help. </p> mjklaim@… https://svn.boost.org/trac10/ticket/10316 https://svn.boost.org/trac10/ticket/10316 Report #10424: future/shared_future::then() in case of continuation return an invalid future Sat, 30 Aug 2014 08:50:59 GMT Sun, 28 Sep 2014 22:40:41 GMT <p> Add this behavior to future/shared_future::then() </p> <ul><li>In case of implicit unwrapping, the validity of the <code>future</code> returned from <code>then</code> cannot be established until after the completion of the functor passed into <code>then</code>. In such case, the resulting <code>future</code> becomes ready with an exception of type <code>future_error</code>, with an error code of <code>future_errc::broken_promise</code>. </li></ul> viboes https://svn.boost.org/trac10/ticket/10424 https://svn.boost.org/trac10/ticket/10424 Report #10550: Implicit unwrapping from then() calls Sat, 27 Sep 2014 16:00:45 GMT Sun, 28 Sep 2014 22:41:28 GMT <p> Follows the Fundamental TS wording for ::then() function. </p> viboes https://svn.boost.org/trac10/ticket/10550 https://svn.boost.org/trac10/ticket/10550 Report #10551: Make futures returned by then()/when_all/when_any don't block. Sat, 27 Sep 2014 16:25:20 GMT Sat, 27 Sep 2014 16:26:27 GMT <p> Follows the Fundamental TS wording for ::then()/ when_all/when_any functions. </p> viboes https://svn.boost.org/trac10/ticket/10551 https://svn.boost.org/trac10/ticket/10551 Report #10610: Add unwrap shared_future constructor Sun, 05 Oct 2014 10:17:57 GMT Sun, 05 Oct 2014 10:21:25 GMT <p> Following N4123, add unwrap shared_future constructor </p> <p> See also <a class="ext-link" href="https://github.com/cplusplus/concurrency_ts/issues/58"><span class="icon">​</span>https://github.com/cplusplus/concurrency_ts/issues/58</a> </p> <pre class="wiki"> shared_future(future&lt;shared_future&lt;R&gt;&gt;&amp;&amp; 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. </pre> viboes https://svn.boost.org/trac10/ticket/10610 https://svn.boost.org/trac10/ticket/10610 Report #10878: boost::thread::attributes -> no non-variadic-support Tue, 16 Dec 2014 22:12:16 GMT Fri, 02 Sep 2016 20:55:32 GMT <p> In terms of applying thread attributes right now the documentation describes only this signature: </p> <p> template&lt;typename Callable&gt; thread(attributes&amp; attrs, Callable func); </p> <p> but this does not work when variadics are not supported (leading to error: type 'boost::thread_attributes' does not provide a call operator) </p> <p> Nevertheless, this temporaray way works out: </p> <p> thread(attributes&amp; attrs, boost::bind(Callable func)); </p> a.carot@… https://svn.boost.org/trac10/ticket/10878 https://svn.boost.org/trac10/ticket/10878 Report #10914: Add a future::notify_when_ready function Wed, 07 Jan 2015 02:46:17 GMT Wed, 07 Jan 2015 02:46:29 GMT <p> This function should help to implement a generic wait_for_any on models of Future. </p> viboes https://svn.boost.org/trac10/ticket/10914 https://svn.boost.org/trac10/ticket/10914 Report #10915: Change wait_for_any to work on models of Future. Wed, 07 Jan 2015 02:47:53 GMT Wed, 07 Jan 2015 02:48:00 GMT <p> Using notify_when_any implement a generic wait_for_any on models of Future. </p> viboes https://svn.boost.org/trac10/ticket/10915 https://svn.boost.org/trac10/ticket/10915 Report #10916: Change wait_for_all to work on models of Future. Wed, 07 Jan 2015 02:48:57 GMT Wed, 07 Jan 2015 02:49:06 GMT viboes https://svn.boost.org/trac10/ticket/10916 https://svn.boost.org/trac10/ticket/10916 Report #10966: packaged_task::reset should not reuse the shared state to conform to C++11 Sat, 24 Jan 2015 09:51:16 GMT Mon, 26 Jan 2015 07:33:49 GMT <p> The standard says </p> <pre class="wiki">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. </pre><p> Boost.Thread reuse the shared state. </p> <pre class="wiki">Effects: Reset the state of the packaged_task so that it can be called again. </pre> viboes https://svn.boost.org/trac10/ticket/10966 https://svn.boost.org/trac10/ticket/10966 Report #11041: Add no_unit to duration_style. Tue, 17 Feb 2015 19:08:27 GMT Sat, 05 Mar 2016 09:32:21 GMT <p> 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'). </p> rkawulak https://svn.boost.org/trac10/ticket/11041 https://svn.boost.org/trac10/ticket/11041 Report #11052: Make all executors copyable pointing to a shared context Fri, 20 Feb 2015 14:08:23 GMT Tue, 29 Sep 2015 20:18:58 GMT <p> Ensuring that the lifetime of an executor is longer than the continuations could be hard for the user. </p> <p> In particular, the tests add a sleep for to ensure it. This is not robust enough. </p> viboes https://svn.boost.org/trac10/ticket/11052 https://svn.boost.org/trac10/ticket/11052 Report #11264: Add variadic lock_guard of Lockables Sun, 03 May 2015 12:56:45 GMT Thu, 14 May 2015 15:59:40 GMT <p> lock_guard works with <a class="missing wiki">BasicLockable</a>. </p> <p> In order the variadic version to avoid deadlock, it can work only with Lockable, as the use of lock forces it. </p> viboes https://svn.boost.org/trac10/ticket/11264 https://svn.boost.org/trac10/ticket/11264 Report #11552: Warning from chrono that could helpfully be suppressed Tue, 18 Aug 2015 10:58:32 GMT Tue, 22 Aug 2017 20:51:01 GMT <blockquote> <p> Boost.Chrono is emitting warnings with GCC (5.1.0) that cannot be suppressed even using the following cxxflags in the user jamfile </p> </blockquote> <pre class="wiki"> &lt;toolset&gt;gcc:&lt;cxxflags&gt;-Wno-deprecated-declarations &lt;toolset&gt;gcc:&lt;cxxflags&gt;-Wno-long-long &lt;toolset&gt;gcc:&lt;cxxflags&gt;-ftrack-macro-expansion=0 # Suppress note: in expansion of macro </pre><p> and they are repeated on every compilation which is quite annoying when reading the log file. </p> <p> For example: </p> <pre class="wiki">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&lt;boost::int_least64_t, ratio&lt;BOOST_RATIO_INTMAX_C(1), BOOST_RATIO_INTMAX_C(10000000)&gt; &gt; ^ ..\..\../boost/chrono/system_clocks.hpp:77:90: note: in expansion of macro 'BOOST_RATIO_INTMAX_C' # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::duration&lt;boost::int_least64_t, ratio&lt;BOOST_RATIO_INTMAX_C(1), BOOST_RATIO_INTMAX_C(10000000)&gt; &gt; </pre><p> and more... </p> <p> It would be nice if the user would not see these (spurious?) warnings. </p> Paul A. Bristow https://svn.boost.org/trac10/ticket/11552 https://svn.boost.org/trac10/ticket/11552 Report #11717: Associate an Executor used to launch the continuation to a promise/packaged_task constructor. Sat, 10 Oct 2015 14:55:30 GMT Sun, 11 Oct 2015 18:16:01 GMT <p> Currently we have <code>async</code> function that constructs futures associated to an <code>Executor</code>. </p> <p> The <code>then()</code> member function should use this executor to launch the continuation. See <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/11716" title="#11716: Bugs: ::then(f) should inherit the parent Executor (closed: fixed)">#11716</a>. </p> <p> But futures can also have other sources, as e.g. a <code>promise</code> or a <code>packaged_task</code>. This paper proposes the addition of <code>Executor</code> aware constructors for <code>promise&lt;T&gt;</code> and <code>packaged_task&lt;R(Args)&gt;</code> so that the continuation on the associated future make use of this executor. </p> <p> We propose to: </p> <ul><li>Add <code>promise&lt;T&gt;::promise&lt;T&gt;(Executor&amp;)</code> Executor aware constructor. </li></ul><ul><li>Add <code>packaged_task&lt;R(Args...)&gt;::packaged_task(Executor&amp;)</code> Executor aware constructor. </li></ul> viboes https://svn.boost.org/trac10/ticket/11717 https://svn.boost.org/trac10/ticket/11717 Report #11773: Extract close/closed to a more specific shutdonw-executor interface. Thu, 29 Oct 2015 13:11:31 GMT Thu, 29 Oct 2015 13:13:45 GMT viboes https://svn.boost.org/trac10/ticket/11773 https://svn.boost.org/trac10/ticket/11773 Report #11774: Extract try_executing_one, reschedule_until to a more specific reentrant executor interface. Thu, 29 Oct 2015 13:12:35 GMT Thu, 29 Oct 2015 13:12:58 GMT viboes https://svn.boost.org/trac10/ticket/11774 https://svn.boost.org/trac10/ticket/11774 Report #12416: Windows: shared_mutex::state_data exceptions thrown in synthetic tests Sun, 28 Aug 2016 23:21:13 GMT Sun, 19 Feb 2017 10:53:41 GMT <p> Hi, My name is Tomer Gal. </p> <p> 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: </p> <blockquote> <p> struct state_data { </p> <blockquote> <p> unsigned shared_count:11, </p> <blockquote> <p> shared_waiting:11, exclusive:1, upgrade:1, exclusive_waiting:7, exclusive_waiting_blocked:1; </p> </blockquote> </blockquote> </blockquote> <p> 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. </p> <p> 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. </p> <p> Could this be fixed? </p> <p> Regards, Tomer Gal, CTO at <a class="missing wiki">OpTeamizer</a> </p> Tomer Gal <Tomer.Gal@…> https://svn.boost.org/trac10/ticket/12416 https://svn.boost.org/trac10/ticket/12416 Report #11619: Chrono V2 IO - format tags 'unsupported'? Fri, 04 Sep 2015 20:24:43 GMT Fri, 11 Sep 2015 17:02:24 GMT <p> <a href="http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.io.ios_state_hpp.sag.set_time_fmt">http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.io.ios_state_hpp.sag.set_time_fmt</a> </p> <p> 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. </p> steve.hickman@… https://svn.boost.org/trac10/ticket/11619 https://svn.boost.org/trac10/ticket/11619 Report #11633: chrono IO V1 may throw bad_cast Wed, 09 Sep 2015 14:59:45 GMT Mon, 28 Aug 2017 05:19:54 GMT <p> I had occurences of chrono io throwing bad_cast exceptions, which lead to backtraces like this one: </p> <pre class="wiki"> #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&lt;boost::chrono::duration_punct&lt;char&gt; &gt; (__loc=...) at /usr/include/c++/4.8/bits/locale_classes.tcc:137 #3 0x00007ffff2288c61 in boost::chrono::operator&lt;&lt; &lt;char, std::char_traits&lt;char&gt;, boost::rational&lt;int&gt;, boost::ratio&lt;1l, 1l&gt; &gt; (os=..., d=...) at /home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include/boost/chrono/io_v1/chrono_io.hpp:210 </pre><p> I think the attached minimal example reproduces the issue. </p> <p> Here the compile &amp; run log using boost 1.58 </p> <pre class="wiki">$ make clean &amp;&amp; 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 </pre><p> Here is the code around boost/include/boost/chrono/io_v1/chrono_io.hpp:210 </p> <pre class="wiki">template &lt;class CharT, class Traits, class Rep, class Period&gt; std::basic_ostream&lt;CharT, Traits&gt;&amp; operator&lt;&lt;(std::basic_ostream&lt;CharT, Traits&gt;&amp; os, const duration&lt;Rep, Period&gt;&amp; d) { typedef duration_punct&lt;CharT&gt; Facet; std::locale loc = os.getloc(); if (!std::has_facet&lt;Facet&gt;(loc)) os.imbue(std::locale(loc, new Facet)); const Facet&amp; f = std::use_facet&lt;Facet&gt;(os.getloc()); //&lt;&lt;&lt;&lt;&lt;&lt;&lt; line210, throw here return os &lt;&lt; d.count() &lt;&lt; ' ' &lt;&lt; f.template name&lt;Period&gt;(d.count()); } </pre><p> maybe we could avoid calling os.getloc() again at line 210 to avoid the race? </p> Sébastien Barthélémy <barthelemy@…> https://svn.boost.org/trac10/ticket/11633 https://svn.boost.org/trac10/ticket/11633 Report #11639: document std's vs boost's chrono::steady_clock system-wideness discrepancy Thu, 10 Sep 2015 08:20:34 GMT Sun, 25 Oct 2015 23:49:58 GMT <p> 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 </p> <pre class="wiki">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. </pre><p> As far as I know, the C++11 standard does not make this requirement. </p> <p> 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. </p> Sébastien Barthélémy <barthelemy@…> https://svn.boost.org/trac10/ticket/11639 https://svn.boost.org/trac10/ticket/11639 Report #13408: Boost Library Possible memory Leak Fri, 19 Jan 2018 14:30:46 GMT Sat, 14 Apr 2018 06:37:19 GMT <p> Hi, </p> <p> 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. </p> <pre class="wiki">==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&lt;boost::detail::tss_cleanup_function&gt;, 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&lt;boost::detail::tss_cleanup_function&gt;, 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&amp;, boost::log::v2_mt_posix::attribute const&amp;) </pre><p> It seems like the allocated memory is not deallocated, so it causes memory leak. Here is the definition of relevant event ; </p> <pre class="wiki"> thread_data_base* make_external_thread_data() { thread_data_base* const me(detail::heap_new&lt;externally_launched_thread&gt;()); me-&gt;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; } </pre><p> 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 ? </p> <p> Thanks in advance, </p> <p> Kind Regards </p> anonymous https://svn.boost.org/trac10/ticket/13408 https://svn.boost.org/trac10/ticket/13408 Report #13599: condition_variable::timed_wait never returns Thu, 14 Jun 2018 03:04:33 GMT Tue, 11 Sep 2018 21:29:43 GMT <p> boost::condition_variable::timed_wait never returns if compiled with -DBOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC. </p> <p> 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. </p> <p> This can be worked around by using condition_variable::wait_for. </p> <p> The following simple test program demonstrates the problem in that it hangs forever. Removing the #define makes it return after one second. </p> <pre class="wiki">#define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC #include &lt;boost/thread.hpp&gt; #include &lt;iostream&gt; 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 &lt;&lt; "wait_for has returned" &lt;&lt; std::endl; return 0; } </pre> steven.cook@… https://svn.boost.org/trac10/ticket/13599 https://svn.boost.org/trac10/ticket/13599 Report #11252: make make_ready_future more efficient Wed, 29 Apr 2015 23:37:32 GMT Sun, 03 May 2015 20:55:53 GMT <p> this function should be more efficient using a specific shared_state constructor. </p> viboes https://svn.boost.org/trac10/ticket/11252 https://svn.boost.org/trac10/ticket/11252 Report #11798: Implementation of boost::shared_mutex on POSIX is suboptimal Mon, 16 Nov 2015 12:52:52 GMT Wed, 13 Dec 2017 02:08:35 GMT <p> 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. </p> <p> 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. </p> alex@… https://svn.boost.org/trac10/ticket/11798 https://svn.boost.org/trac10/ticket/11798 Report #12433: Make use of make_shared whenever possible in future.hpp Sat, 03 Sep 2016 18:06:36 GMT Sat, 03 Sep 2016 18:06:47 GMT <p> 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. </p> viboes https://svn.boost.org/trac10/ticket/12433 https://svn.boost.org/trac10/ticket/12433 Report #2438: gcc.jam sets LD_LIBRARY_PATH which breaks FreeBSD build Mon, 27 Oct 2008 16:57:06 GMT Mon, 11 Jan 2010 17:10:44 GMT <p> In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to: </p> <p> /usr/bin:/usr/lib:/usr/lib32:/usr/lib64 </p> <p> Couple of points: </p> <ul><li>/usr/bin (?) :D </li><li>/usr/lib on FreeBSD does not contain major number libs so most if not all binaries will not pick up anything from here </li><li>/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 </li><li>/usr/lib64 does not exist on FreeBSD (I believe this is a Linux thing) </li></ul><p> 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. </p> <p> Thread: </p> <p> <a class="ext-link" href="http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html"><span class="icon">​</span>http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html</a> </p> <p> 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). </p> pisymbol@… https://svn.boost.org/trac10/ticket/2438 https://svn.boost.org/trac10/ticket/2438 Report #2732: boost bjam install respects umask Thu, 05 Feb 2009 21:19:52 GMT Tue, 10 Nov 2009 08:17:53 GMT <p> Using bjam to install boost 1.37 the install procedure respects the current umask of the user. </p> <p> 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'). </p> <p> 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. </p> <p> 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 </p> gsauthof@… https://svn.boost.org/trac10/ticket/2732 https://svn.boost.org/trac10/ticket/2732 Report #3550: specify toolset to bootstrap.bat Fri, 23 Oct 2009 15:14:14 GMT Sun, 19 Dec 2010 22:05:03 GMT <p> Hi, </p> <p> 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. </p> <p> 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) </p> <p> cheers Chris </p> bielow@… https://svn.boost.org/trac10/ticket/3550 https://svn.boost.org/trac10/ticket/3550 Report #3564: bjam creates wrong library name when toolset choice is invalid Mon, 26 Oct 2009 15:25:57 GMT Tue, 10 Nov 2009 07:11:18 GMT <p> Hi, </p> <p> 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: --&gt; libboost_math_tr1l-vc-mt-gd-1_40.lib which should be --&gt; libboost_math_tr1l-vc90-mt-gd-1_40.lib </p> <p> 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 (<a href="http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.msvc">http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.msvc</a>). At least the toolset docu (<a href="http://www.boost.org/doc/libs/1_40_0/more/getting_started/windows.html#identify-your-toolset">http://www.boost.org/doc/libs/1_40_0/more/getting_started/windows.html#identify-your-toolset</a>) could use the above link! </p> <p> So, is it possible to introduce white-lists for the toolset options to avoid this kind of error?! </p> bielow@… https://svn.boost.org/trac10/ticket/3564 https://svn.boost.org/trac10/ticket/3564 Report #1094: Finding the correct library to link (feature request for pkg-config support)h Mon, 16 Jul 2007 17:41:27 GMT Wed, 06 Jun 2018 12:34:57 GMT <p> 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. </p> <p> I make use of several Boost libraries in my schroot program (<a class="ext-link" href="svn://svn.debian.org/svn/buildd-tools/trunk/schroot"><span class="icon">​</span>svn://svn.debian.org/svn/buildd-tools/trunk/schroot</a>). </p> <p> 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. </p> <p> To illustrate my problem: </p> <blockquote> <p> ls -l /usr/lib/libboost_regex-*.so /usr/lib/libboost_program_options-*.so </p> </blockquote> <p> lrwxrwxrwx 1 root root 45 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-1_34.so -&gt; 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 -&gt; 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 -&gt; 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 -&gt; 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 -&gt; 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 -&gt; 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 -&gt; libboost_regex-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 28 2007-07-08 11:47 /usr/lib/libboost_regex-st.so -&gt; libboost_regex-gcc41-1_34.so </p> <p> 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. </p> <p> 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. </p> <p> To further show the problem I am having, this is part of my configure.ac Autoconf template: </p> <p> ---configure.ac---- AC_CHECK_HEADERS([tr1/memory]) </p> <p> AC_CHECK_HEADERS([boost/shared_ptr.hpp]<sub> [ </sub></p> <blockquote> <p> if test $ac_cv_header_tr1_memory = yes; then </p> <blockquote> <p> : </p> </blockquote> <p> else </p> <blockquote> <p> AC_MSG_ERROR([Boost.shared_ptr (Boost C++ Libraries) is not installed, but is required by schroot]) </p> </blockquote> <p> fi]) </p> </blockquote> <p> AC_CHECK_HEADERS([tr1/tuple]) </p> <p> AC_CHECK_HEADERS([boost/tuple/tuple.hpp]<sub> [ </sub></p> <blockquote> <p> if test $ac_cv_header_tr1_memory = yes; then </p> <blockquote> <p> : </p> </blockquote> <p> else </p> <blockquote> <p> AC_MSG_ERROR([Boost.Tuple (Boost C++ Libraries) is not installed, but is required by schroot]) </p> </blockquote> <p> fi]) </p> </blockquote> <p> AC_CHECK_HEADERS([boost/format.hpp]<sub> [AC_MSG_ERROR([Boost.Format (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/program_options.hpp]</sub> [AC_MSG_ERROR([Boost.Program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/type_traits.hpp]<sub> [AC_MSG_ERROR([Boost.<a class="missing wiki">TypeTraits</a> (Boost C++ Libraries) is not installed, but is required by schroot])]) </sub></p> <p> 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(<a class="assigned ticket" href="https://svn.boost.org/trac10/ticket/1094#include" title="#1094: Feature Requests: Finding the correct library to link (feature request for pkg-config ... (assigned)">&lt;boost/program_options.hpp&gt;</a>, </p> <blockquote> <p> [boost::program_options::variables_map::variables_map dummy()])], </p> </blockquote> <blockquote> <p> [AC_MSG_RESULT([yes]) </p> <blockquote> <p> BOOST_LIBS="${BOOST_LIBS} -lboost_program_options-st"], </p> </blockquote> <p> [AC_MSG_RESULT([no]) </p> <blockquote> <p> AC_MSG_FAILURE([libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) </p> </blockquote> </blockquote> <p> LDFLAGS="${saved_ldflags}" </p> <p> 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(<a class="assigned ticket" href="https://svn.boost.org/trac10/ticket/1094#include" title="#1094: Feature Requests: Finding the correct library to link (feature request for pkg-config ... (assigned)">&lt;boost/program_options.hpp&gt;</a>, </p> <blockquote> <p> [boost::program_options::options_description testgrp("test group"); </p> <blockquote> <p> bool notused = testgrp.options().empty(); </p> </blockquote> </blockquote> <p> ])], </p> <blockquote> <p> [AC_MSG_RESULT([yes]) </p> <blockquote> <p> BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS="current"], </p> </blockquote> <p> [AC_MSG_RESULT([no]) </p> <blockquote> <p> BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS="old"]) </p> </blockquote> </blockquote> <p> 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 </p> <blockquote> <p> AC_DEFINE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, 1) </p> </blockquote> <p> fi </p> <p> AC_MSG_CHECKING([for boost::regex in -lboost_regex-st]) saved_ldflags="${LDFLAGS}" LDFLAGS="${LDFLAGS} -lboost_regex-st" AC_LINK_IFELSE([AC_LANG_PROGRAM(<a class="assigned ticket" href="https://svn.boost.org/trac10/ticket/1094#include" title="#1094: Feature Requests: Finding the correct library to link (feature request for pkg-config ... (assigned)">&lt;boost/regex.hpp&gt;</a>, </p> <blockquote> <p> [boost::regex(&#34;^foo[bar]$")])], </p> </blockquote> <blockquote> <p> [AC_MSG_RESULT([yes]) </p> <blockquote> <p> BOOST_LIBS="${BOOST_LIBS} -lboost_regex-st"], </p> </blockquote> <p> [AC_MSG_RESULT([no]) </p> <blockquote> <p> AC_MSG_FAILURE([libboost_regex (Boost C++ Libraries) is not installed, but is required by schroot])]) </p> </blockquote> </blockquote> <p> LDFLAGS="${saved_ldflags}" </p> <p> AC_SUBST([BOOST_LIBS]) </p> <p> ---configure.ac---- </p> <p> 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. </p> <p> 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: </p> <hr /> <p> prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include </p> <p> 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 </p> <hr /> <p> You can generate this from a template: </p> <hr /> <p> prefix=PREFIX exec_prefix=EPREFIX libdir=LIBDIR includedir=INCLUDEDIR </p> <p> 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 </p> <hr /> <p> 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. </p> <p> For such a setup, all that configure script above could be mostly reduced to </p> <blockquote> <p> PKG_CHECK_MODULES([boost-regex-st]) PKG_CHECK_MODULES([boost-program-options-st]) </p> </blockquote> <p> 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. </p> <p> You may find much more detailed discussion of these issues at </p> <blockquote> <p> <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038</a> <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666</a> <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264</a> <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419</a> <a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539</a> </p> </blockquote> <p> 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. </p> <p> Regards, Roger </p> <p> -- </p> <blockquote> <p> .<em>`. Roger Leigh </em></p> </blockquote> <blockquote> <p> : :' : Debian GNU/Linux <a class="ext-link" href="http://people.debian.org/~rleigh/"><span class="icon">​</span>http://people.debian.org/~rleigh/</a> <code>. </code>' Printing on GNU/Linux? <a class="ext-link" href="http://gutenprint.sourceforge.net/"><span class="icon">​</span>http://gutenprint.sourceforge.net/</a> </p> <blockquote> <p> `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. </p> </blockquote> </blockquote> rleigh@… https://svn.boost.org/trac10/ticket/1094 https://svn.boost.org/trac10/ticket/1094 Report #2746: Please allow specifying the library SONAME in Jamroot Wed, 11 Feb 2009 02:11:36 GMT Mon, 09 Nov 2009 18:03:08 GMT <p> 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). </p> <p> Here is the related thread from the luabind-user mailing list: </p> <p> <a class="ext-link" href="http://news.gmane.org/find-root.php?message_id=%3c20090131051842.GA15718%40connexer.com%3e"><span class="icon">​</span>http://news.gmane.org/find-root.php?message_id=%3c20090131051842.GA15718%40connexer.com%3e</a> </p> <p> 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. </p> roberto@… https://svn.boost.org/trac10/ticket/2746 https://svn.boost.org/trac10/ticket/2746 Report