__group__ ticket summary component milestone type created _changetime _description _reporter acharles 2628 Sequence concept incorrectly fails for basic_string concept_check Boost 1.56.0 Bugs 2009-01-01T03:38:48Z 2014-02-21T09:24:23Z "The Sequence concept fails when tested against basic_string (e.g. BOOST_CONCEPT_ASSERT((Sequence)); ) because an extra constructor test is included. This test is for X a(n) where n is the size of the sequence to be created. However, section 23.1.1 table 67 of the C++ standard does not include this test in the definition of the Sequence concept. Because this test is in place, basic_string is rejected by the current implementation of the Sequence concept, since basic_string does not have this constructor. However, section 21.3 paragraph 2 of the C++ standard states, ""The class template basic_string conforms to the requirements of a Sequence, as specified in (23.1.1)."" The fix for this should be as simple as removing the test for a constructor of the form X a(n) in the Sequence concept implementation." Joel Lathrop acharles 7729 concept_def.hpp multiple inclusion prevention macro bug graph Boost 1.56.0 Bugs 2012-11-23T14:35:43Z 2014-02-21T09:35:24Z "In boost/concept/detail/concept_def.hpp, the BOOST_CONCEPT_DETAIL_CONCEPT_DEF_DWA200651_HPP macro does not apply to the whole include file (search for its pending endif). As a consequence, the following warning appearing e.g. when including boost/graph/adjacency_list.hpp: {{{ ""BOOST_concept"" redefined [...] }}} " moala@… acharles 9939 "Patch to add ""no exceptions"" support to dynamic_bitset" dynamic_bitset Boost 1.56.0 Patches 2014-04-22T22:09:13Z 2014-08-21T14:47:23Z "This patch adds support for compiling with exceptions disabled by using BOOST_TRY/BOOST_CATCH etc. " Boleslaw Ciesielski agurtovoy 1215 Boost 1.34.1, mpl: Wrong workaround detection using MinGW32 (or.hpp, line #33) mpl To Be Determined Bugs 2007-08-26T15:31:24Z 2010-01-25T01:20:08Z "#if defined(_MSC_VER) is not the right thing for MinGW because _MSC_VER is defined but the compiler is still from GNUs Compiler Collection. But i am not sure about the MinGW support in general. Regard, Hans." hfp@… agurtovoy 1549 Boost.MPL: 'index_of' algorithm is not documented mpl Boost 1.36.0 Bugs 2008-01-04T02:24:33Z 2008-01-04T02:24:52Z Aleksey Gurtovoy agurtovoy 2041 "MPL: more comprehensive test coverage for ""fail"" situations requiring diagnostics" mpl Boost 1.36.0 Bugs 2008-06-23T21:07:19Z 2008-06-23T21:07:36Z See http://thread.gmane.org/gmane.comp.lib.boost.user/36876 Aleksey Gurtovoy andreas_huber69 4064 std::bad_cast should be thrown with BOOST_THROW_EXCEPTION statechart Boost 1.46.0 Bugs 2010-04-04T10:33:25Z 2010-11-06T08:11:07Z "Also, other try/catch/throw statements should be put into appropriate #ifndef blocks. Reported by Thomas Mathys." Andreas Huber andreas_huber69 6894 Highlight context forwarding in async state machine docs statechart To Be Determined Bugs 2012-05-13T21:17:44Z 2013-06-09T18:03:25Z (as reported by Sebastian Hoffmann) Andreas Huber andreas_huber69 4063 Add debugging support statechart Boost 1.47.0 Feature Requests 2010-04-04T09:48:56Z 2010-11-06T08:09:26Z See Andreas Huber andreas_huber69 4062 Write a FAQ item on why state constructors do not have access to event data statechart Boost 1.46.0 Tasks 2010-04-04T09:33:16Z 2013-12-15T14:42:02Z "The following techniques should be mentioned: - transition actions & store data in an outer state - repost in transition action & react in an in-state reaction - triggering_event" Andreas Huber artyom 9827 Missing support for some code page(e.g 949, 950) in windows conversion with std backend locale To Be Determined Bugs 2014-04-02T09:55:42Z 2017-07-13T14:51:24Z "There is a table windows_encoding all_windows_encodings[] in wconv_codepage.ipp. It contains several code page definitions. However, it misses some code pages, such as the Korean code page(949) or Traditional Chinese Big5 code page(950), which will cause an invalid_charset_error when running in that windows for the following code: {{{ // Assuming we are using the std backend so it supports ansi encodings boost::locale::generator gen; gen.use_ansi_encoding(true); std::locale loc(gen("""")); // Throws invalid_charset_error when running in Korean windows but OK in English windows. // The charset is ""windows949"" in Korean windows, which is not in the table. std::string us = boost::locale::conv::to_utf(""abcdefg"", loc); }}} The root cause of this exception is that the generated code page string is not in the table. When the locale generator with std backend in windows platform generates a locale, it calls boost::locale::util::get_system_locale(bool use_utf8). This function will use the following code to generate the locale string(in default_locale.cpp): {{{ if(GetLocaleInfoA(LOCALE_USER_DEFAULT,LOCALE_IDEFAULTANSICODEPAGE,buf,sizeof(buf))!=0) { if(atoi(buf)==0) lc_name+="".UTF-8""; else { lc_name +="".windows-""; lc_name +=buf; } } }}} So the encoding part of the lc_name is windows-(code page). In a system with Korean(949) or Traditional Chinese(950) code page, this will generate an encoding string like ""windows-949"" or ""windows-950"". However, when wconv_from_utf::open() initializes, it tries to search ""windows949"" or ""windows950"" in array all_windows_encodings[]. Obviously it will not find the string, and the open() fails, then the exception is thrown. For a quick fix, I suggest adding the missing code page to the table: {{{ { ""cp949"", 949, 0 }, // Korean { ""uhc"", 949, 0 }, // From ""iconv -l"" { ""windows949"", 949, 0 }, // Korean // ""big5"" already in the table { ""windows950"", 950, 0 }, // TC, big5 }}} However the list may not be complete, and we may encounter problems when running in a system with code page that does not exist in the list. So we may probably add the following code to function int encoding_to_windows_codepage(char const *ccharset) in wconv_codepage.ipp: {{{ --- E:\Build1\boost_1_55_0\libs\locale\src\encoding\wconv_codepage.ipp 2014-04-02 16:34:52.000000000 +0800 +++ E:\Build2\boost_1_55_0\libs\locale\src\encoding\wconv_codepage.ipp 2014-04-02 17:31:37.000000000 +0800 @@ -206,12 +206,18 @@ return ptr->codepage; } else { return -1; } } + if(ptr==end && charset.size()>7 && charset.substr(0,7)==""windows"") { + int cp = atoi(charset.substr(7).c_str()); + if(IsValidCodePage(cp)) { + return cp; + } + } return -1; } template bool validate_utf16(CharType const *str,unsigned len) }}} This piece of code directly parses and validates the encoding string. The concern is that the call to IsValidCodePage may decrease the performance(not tested)." hucaonju@… artyom 11848 Win32 backend bug when do wide char convert to multi byte in boost::locale locale To Be Determined Bugs 2015-12-16T05:26:31Z 2015-12-16T11:47:20Z "The function wide_to_multibyte_non_zero in locale/src/encoding/wconv_codepage.ipp has bug. This function assume that when the codepage is CP_UTF7 or CP_UTF8, the substitute_ptr and subst_char_ptr will be 0. But, in x64 Windows 10, I use codepage 54936 get 87 error code after the first WideCharToMultiByte called. This will make n is zero, and the second WideCharToMultiByte call will make the program crash. In MSDN shipped with Visual Studio .NET 2003 it is said that parameters lpDefaultChar and lpUsedDefaultChar must be NULL not only for CP_UTF7 and CP_UTF8, but also for all codepages mentioned in notes for dwFlags parameter: 50220 50221 50222 50225 50227 50229 57002 through 57011 65000 (UTF-7) 42 (Symbol) It is still true as of Windows 8 & 10: if you try to call BOOL bVal = FALSE; WideCharToMultiByte(50220, 0, L""asdf"", 4, NULL, 0, NULL, &bVal); You'll get 0 with GetLastError 87 (ERROR_INVALID_PARAMETER)." fyrestone@… artyom 9685 Boost.Locale does not link against static ICU on Windows locale To Be Determined Feature Requests 2014-02-19T23:06:28Z 2016-12-08T14:40:25Z "There seems to be no support for linking against the static ICU libraries (sicuXX.lib) on Windows. Is there any plans to add it (?), or is there an inherent problem? I would be willing to write that support if there is a bit of guidance on how to go about it in the Jamfile." stathis@… artyom 7266 Gettext path formats. locale Boost 1.54.0 Patches 2012-08-23T05:47:10Z 2013-01-07T06:37:55Z "{{{ I'm extremely happy about Boost.Locale, but I've found a few things lacking. So at first I wrote a some wrappers to get around a few flaws with my usage of Boost.Locale. One of these flaws was how it's hardcoded to use the Gettext directory hierarchy. I'd rather store my stuff in 'lang/en_US.mo' rather than 'lang/en_US/LC_MESSAGES/my_app.mo'. The patch adds a 'path format' feature, which allows you to format the directory structure when finding Gettext catalogs, to achieve the effect above. All you really have to do is run: gen.add_path_format(""{1}/{2}.mo""); // Use a smaller hierarchy. to achieve the result that I prefer, or gen.add_path_format(""{1}/{2}/{3}/{4}.mo""); // Use a Gettext hierarchy. to achieve the result that Boost.Locale uses right now. Ripped straight from Doxygen comments: {1} A path to search for catalogs in. {2} The locale's name. {3} The locale's category. {4} The Gettext domain. }}} I apologize for the cut and paste from it but I'm having trouble with trac. The full thread with patches can be found at: http://lists.boost.org/Archives/boost/2012/08/195789.php" 166291@… asutton 3478 Min cut interface for BGL graph To Be Determined Feature Requests 2009-09-22T14:00:56Z 2010-12-08T19:44:44Z "1) The max flow can be obtained with: (any of the max_flow algorithms, kolmogorov is just used as an example) double flow = kolmogorov_max_flow(g, SourceNode, SinkNode); It would be nice to also interpret this max flow as a min cut. I.e. be able to tell which nodes of g belong to the ""source side"" of the graph and which nodes belong to the ""sink side""? Maybe something like a std::vector GetSourceSideNodes(); //return the IDs of the nodes on the source side std::vector GetSinkSideNodes();//return the IDs of the nodes on the sink side std::vector GetCutEdges(); // return the IDs of the edges which were cut 2) Allow the min cut algorithm to accept multiple sources/sinks. The cut should simply be the minimum sum of edges that can be severed to split the graph so that all of the sinks are on one side of the cut and all of the sources are on the other side of the cut. 3) Find the minimum cut that partitions the graph into two parts without specifying a source/sink? I.e. the minimum of all of the possible source/sink pairs minium cuts. 4) Currently you must use a bidirectional graph, and specify an edge_reverse_t in the graph traits, then set the reverse edge for every edge. a) this is pretty complicated for someone who is unfamiliar with generic programming. b) If an undirected graph is used, the algorithm should automatically take care of adding these reverse edges if they are required for the cut to be performed. 5) VERY simple examples (actually constructing a graph (not reading it from file) with < 10 nodes) should be provided to demonstrate all of these cases." David Doria asydorchuk 6063 resize does not offset rectangles (etc.) correctly or crashes polygon To Be Determined Bugs 2011-10-26T21:18:46Z 2014-02-10T22:06:28Z "When using the 'corner_fill_arc' parameter to polygon_set_concept::resize(), a minkowski sum using a polygonalized circle is used to get the offset shape. A symptom of the problem is demonstrated by the following code: {{{ { polygon_set_data ps1, ps2, ps3; ps1.insert(rectangle_data(0, 0, 50, 50)); ps2.insert(rectangle_data(0, 0, 50, 50)); ps3.insert(rectangle_data(0, 0, 50, 50)); std::cout << ""rect before resize: "" << ps1 << std::endl; ps1.resize(6, true, 0); ps2.resize(6, true, 5); ps3.resize(6, true, 6); rectangle_data ps1_extents, ps2_extents, ps3_extents; extents(ps1_extents, ps1); extents(ps2_extents, ps2); extents(ps3_extents, ps3); std::cout << ""extents of resized rect with '0' (4) segments in circle: "" << ps1_extents << std::endl; std::cout << ""extents of resized rect with 5 segments in circle: "" << ps2_extents << std::endl; std::cout << ""extents of resized rect with 6 segments in circle: "" << ps3_extents << std::endl; } }}} If I put this at the end of the gtl_boost_unit_test.cpp, I get the following output: {{{ rect before resize: Polygon Set Data { <0 0, 50 0>:1 <50 0, 50 50>:-1 <0 50, 50 50>:-1 <0 0, 0 50>:1 } extents of resized rect with '0' (4) segments in circle: -5 54 -5 54 extents of resized rect with 5 segments in circle: -6 54 -6 55 extents of resized rect with 6 segments in circle: -6 55 -6 56 }}} This shows that the extents of the offset shape vary as the number of segments does - which should not be the case! The extents should all be: -6 56 -6 56 ---- The problem (to my eyes) is that the polygonalized circle does not generally have the right shape to get proper offsets in axis-oriented directions, so the offset is basically multiplied by some factor of sqrt(2). Attached is an image of the circle generated with num_circle_segments=16. The radius of the circle - i.e. distance from center to each vertex - is 2. The grid spacing is 1. As can be seen, the top/bottom and left/right sides of the circle do not lie on the grid. If the circle started with a vertex at(0,2) this would not occur and one would presumably get proper offsets in axis-aligned directions. Alternately one could offset all the vertices slightly farther, but this would offset some vertices farther than desired. I would guess the fix is to change the behaviour of make_arc(), which generates these points, but I'm not sure exactly what the original author's intent was - so maybe just using a new function would be best (after all, the complexity of make_arc is overkill when you're generating a simple full circle) ---- Another problem is that the behaviour of the 'corner_fill_arc' parameter is not really well described. Using this gives much more than corner-filling behaviour - it gives different offsets in different directions. I would suggest explaining it as it is - a minkowski sum with a polygonalized circle, with all that implies. E.g. for a 45-degree segment the offset will differ from a 90-degree segment unless you pick the right value of num_circle_segments. Maybe a more comprehensible solution would be to implement corner rounding by the intersection of the normal resize()d shape (as given by corner_fill_arc=false) with the resize()d shape given by corner_fill_arc=true with a larger 'resizing' (picked so that the minimum resizing equals the original resizing). This would only affect corners, instead of the whole shape. " dbfaken@… asydorchuk 7984 In very rare cases, boost::polygon crashed or generate bad polygon when substracting 2 sets of polygons polygon To Be Determined Bugs 2013-02-05T19:25:06Z 2015-01-26T19:53:36Z "I am using boost:: polygon to calculate sum or difference of sets of polygons. Recently, When calcualting the difference of 2 sets of polygons, I found 2 cases creating a serious issue: Depending on the shape of polygons ( a slight change ""fix"" the bug) I have one case which create no polygon and one (in fact 2 samples) which crashes. In the sample which calculate the difference between 2 polygon sets, there are 2 polygon sets: one creates no polygon, and the other crashes. This it reproducible under Linux or Windows-gcc-mingw, with different gcc versions and boost version. (I tried to make the polygons as simple as possible) (see comments inside the sample). I have used a lot boost:: polygon, and I have only 2 cases which fails (Seems related to a particular shape, not to a polygon complexity) Thanks to the developpers." jp.charras@… asydorchuk 11315 Compilation warnings created by boost::polygon::operators polygon To Be Determined Bugs 2015-05-17T18:36:41Z 2015-07-01T17:33:16Z "When I compile bp_warn.cc (attached) with Clang and enable ""-Wall -Werror"", the compilation fails with ""template argument uses unnamed type"". See attached ""warnings.txt"" for complete output. This took me a little while to track down, since the error occurs on a call to ""*"" using primitive types (!). I am not sure this is really a bug in boost::polygon, and I am not sure how to fix it if it is, but I thought I would report it anyway." lopresti@… asydorchuk 11415 crash in processEvent_ polygon To Be Determined Bugs 2015-06-23T10:39:41Z 2017-08-31T09:58:54Z "In polygon/details/polygon_arbitrary_formation.hpp, at the end of function processEvent_ (line 1768), I had a case where iter is dereferenced illegally. Changing line 1741 from: if(verticalTail && !(verticalCount.second)) { to if (verticalTail && !(verticalCount.second) && iter != scanData_.end()) { fixes this problem, but it might be the case that this just misses the addition of a new hole. I have processed many polygons and this only happened with a specific polygon, but looking at the iter determining code earlier in processEvent_ (lines 1669..1698), iter referring to the end of scanData might not be such a special case: iterator iter = lookUp_(currentY); while(iter != scanData_.end() && ((iter->first.pt.x() == x_ && iter->first.pt.y() == currentY) or (iter->first.other_pt.x() == x_ && iter->first.other_pt.y() == currentY))) { elementIters.push_back(iter); ... ++iter; } If the original coder assumed that (verticalTail && !(verticalCount.second)) implies that (iter != scanData_.end()), well, sometimes it does not. I'll provide more info on actual case(s) (instantiation types, coordinates) in additional notes. In the seen case, scanData_ contained 3 elements, and elementIters had 2." mhilferink@… awulkiew 10772 boost::geometry::within() does not recognize empty boxes geometry To Be Determined Bugs 2014-11-08T19:04:31Z 2015-09-07T12:54:36Z "If boost::geometry::within() is used to check whether an empty box (i.e. a point) is within another box, false is always returned. This is not the correct behavior because: 1. OGC defines: a.Within(b) ⇔ (a∩b=a) ∧ (I(a)∩E(b)=∅) which holds true. The intersection of an empty box ''a'' and a surrounding box ''b'' yields ''a''. Since ''a'' has no interior, I(a)=∅, thus the second condition is also true. 2. Empty boxes should be treated as points. When using a point model instead of an empty box, the check returns the correct result as expected. See also the following complete minimal code (it includes also other geometry algorithms that are computed consistently for points and empty boxes): {{{ #include #include #include #include #include #include #include #include // needed for within() -- is this intended? #include namespace bg = boost::geometry; typedef bg::model::d2::point_xy Point; typedef bg::model::box Box; int main() { Point point(3, 4); Box pointAsBox; bg::convert(point, pointAsBox); Box surrounding; surrounding.min_corner() = Point(2, 2); surrounding.max_corner() = Point(5, 5); std::cout << "" Point Box"" << std::endl; std::cout << ""within: "" << bg::within(point, surrounding) << "" "" << bg::within(pointAsBox, surrounding) << ""\n""; // 1 0 <- std::cout << ""within (self): "" << bg::within(point, point) << "" "" << bg::within(pointAsBox, pointAsBox) << ""\n""; // 1 0 <- std::cout << ""covered_by: "" << bg::covered_by(point, surrounding) << "" "" << bg::covered_by(pointAsBox, surrounding) << ""\n""; // 1 1 std::cout << ""intersects: "" << bg::intersects(point, surrounding) << "" "" << bg::intersects(pointAsBox, surrounding) << ""\n""; // 1 1 std::cout << ""disjoint: "" << bg::disjoint(point, surrounding) << "" "" << bg::disjoint(pointAsBox, surrounding) << ""\n""; // 0 0 std::cout << std::endl; } }}} The implementation looks as follows (boost/geometry/strategies/cartesian/box_in_box.hpp, line 32): {{{ struct box_within_range { template static inline bool apply(BoxContainedValue const& bed_min , BoxContainedValue const& bed_max , BoxContainingValue const& bing_min , BoxContainingValue const& bing_max) { return bing_min <= bed_min && bed_max <= bing_max // contained in containing && bed_min < bed_max; // interiors overlap } }; }}} The problem is the second line, which uses < and thus returns false if the coordinates are equal. I'm not sure what the intention is (despite the comment), and whether it is needed at all. The documentation about box model and concept doesn't state whether max_corner's coordinates must be component-wise greater or equal than min_corner's. If so, it seems like valid boxes are a precondition to within() and this line could be removed." bromeon@… awulkiew 11421 [geometry] rstar segmentation fault boost version 1.58.0 geometry To Be Determined Bugs 2015-06-25T20:23:15Z 2016-06-27T12:47:13Z "== Notes: == The segmentation fault does not occur with boost version 1.55.0.[[BR]] Discovered when upgrading from Boost 1.55.0 to Boost 1.58.0.[[BR]] When inserting large numbers (greater than 10^4^) of geometry::model::box objects into an geometry::index::rtree object that uses the boost::geometry::index::rstar algorithm, a segmentation fault occurs. == system information: == gcc (Gentoo 4.8.2 p1.0, pie-0.5.8) 4.8.2[[BR]] Linux dctest1 3.4.0-gentoo-01 #1 SMP Sun May 27 15:51:01 CDT 2012 x86_64 Intel(R) Xeon(R) CPU X5675 @ 3.07GHz GenuineIntel GNU/Linux[[BR]] MemTotal: 198094372 kB == test program used to reproduce segmentation fault: == {{{ // File: test.cpp #include #include #include // 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(NUM_BOXES_LAT); const float DELTA_LON_DEG = (MAX_LON_DEG - MIN_LON_DEG)/static_cast(NUM_BOXES_LON); using COORD_TYPE = boost::geometry::cs::cartesian; using Point = boost::geometry::model::point; using Box = boost::geometry::model::box; using BoxIDPair = std::pair; int main() { // Create a grid of boxes evenly distributed across North America. // Test Note: swap out rtree algorithms to isolate seg fault problem // boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::rstar<16, 4> > locationGeometryTable; // seg fault @ 10^4 boxes boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::rstar<16> > locationGeometryTable; // seg fault @ 10^4 boxes // boost::geometry::index::rtree< BoxIDPair, boost::geometry::index::quadratic<16> > locationGeometryTable; // pass @ 10^4 boxes; pass @ 10^6 for(unsigned idxLat=0; idxLat 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: ... Reading symbols from test...done. (gdb) catch throw Catchpoint 1 (throw) (gdb) run Starting program: test warning: Could not load shared library symbols for linux-vdso.so.1. Do you need ""set solib-search-path"" or ""set sysroot""? Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7651127 in __memmove_ssse3_back () from /lib64/libc.so.6 (gdb) backtrace #0 0x00007ffff7651127 in __memmove_ssse3_back () from /lib64/libc.so.6 #1 0x00000000004165fa in boost::geometry::index::detail::varray_detail::copy_dispatch >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> (first=0x7fffffffc188, last=0x7fffffffc1b8, dst=0x406a6a >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::---Type to continue, or q to quit--- index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+62>) at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray_detail.hpp:201 #2 0x0000000000413ee6 in boost::geometry::index::detail::varray_detail::copy >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> ( first=0x7fffffffc188, last=0x7fffffffc1b8, dst=0x406a6a >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box to continue, or q to quit--- ::geometry::cs::cartesian> >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+62>) at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray_detail.hpp:224 #3 0x0000000000411a03 in boost::geometry::index::detail::varray >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_interna---Type to continue, or q to quit--- l_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, 17ul>::assign_dispatch >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> ( this=0x406a62 >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::apply_visitor >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators to continue, or q to quit--- cator >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+54>, first=0x7fffffffc188, last=0x7fffffffc1b8) at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray.hpp:1774 #4 0x00000000004100b4 in boost::geometry::index::detail::varray >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, 17ul>::assign >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>*> ( this=0x406a62 >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boos---Type to continue, or q to quit--- t::detail::variant::void_>::apply_visitor >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> > >(boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> >&)+54>, first=0x7fffffffc188, last=0x7fffffffc1b8) at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/varray.hpp:950 #5 0x000000000040e698 in boost::geometry::index::detail::rtree::redistribute_elements >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::rstar_tag>::apply >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag> > (n=..., second_node=..., box1=..., box2=..., parameters=..., translator=..., allocators=...) ---Type to continue, or q to quit--- at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/rtree/rstar/redistribute_elements.hpp:442 #6 0x0000000000000003 in ?? () #7 0x00007fffffffca00 in ?? () #8 0x000000000040b798 in boost::geometry::index::detail::rtree::visitors::rstar::level_insert<1ul, boost::geometry::index::detail::rtree::ptr_pair >, boost::variant >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::variant_internal_node >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>*>, std::pair >, unsigned int>, boost::geometry::index::detail::rtree::options, boost::geometry::index::detail::rtree::insert_reinsert_tag, boost::geometry::index::detail::rtree::choose_by_overlap_diff_tag, boost::geometry::index::detail::rtree::split_default_tag, boost::geometry::index::detail::rtree::rstar_tag, boost::geometry::index::detail::rtree::node_variant_static_tag>, boost::geometry::index::detail::translator >, unsigned int> >, boost::geometry::index::equal_to >, unsigned int> > >, boost::geometry::model::box >, boost::geometry::index::detail::rtree::allocators >, unsigned int> >, std::pair >, unsigned int>, boost::geometry::index::rstar<16ul, 4ul, 4ul, 32ul>, boost::geometry::model::box >, boost::geometry::index::detail::rtree::node_variant_static_tag> >::operator() ( this=, n=) at /data/git/dependencies/boost-1.58.0/include/boost/geometry/index/detail/rtree/rstar/insert.hpp:279 Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}} " Celair az_sw_dude 5638 greg_month::get_month_map_ptr is not thread safe date_time To Be Determined Bugs 2011-06-24T08:06:03Z 2015-03-17T16:16:58Z "We recently have found a crash issue related to this function in greg_month.cpp. the block from line 39 is not thread safe. If multiple threads call this function simultaneously, it will lead to a crash. As one thread is populating the map while the other thread may start using the map, or even worse two threads populate the map at the same time. " fatbone az_sw_dude 605 Support different DST rules in timezone db based on years date_time Feature Requests 2006-04-17T13:20:56Z 2010-11-28T06:27:44Z "{{{ The boost time library supports processing of the timezone database file as a .csv, with one entry per time zone, such as ""America/New_York"". However, in 2007, the daylight savings time rules will change. The contents of the csv need to change, to incorporate a range of effective years. Since DST is a spring and fall event (in both north and south hemispheres) only a year need be recorded. I suggest adding two values at the beginning of the line, (as one field in the form nnnn-nnnn) for the low effective-year and high effective-year, as 4-digit values. Let 0000 be used for ""all previous years"" and 9999 be used for all subsequent years. [If the '-' separator is a problem, ':' could be used instead.] Then, the change in 2007 can be recorded as two lines: ""2007-9999"",""America/New_York"", ... ""0000-2006"",""America/New_York"", ... Lines unaffected by the change would have ""0000-9999"" as the first field. }}}" nobody az_sw_dude 889 Insane Dependencies date_time Feature Requests 2007-04-09T23:07:09Z 2009-11-22T20:03:13Z "{{{ From: helvey@accelrys.com Simply including boost/date_time/posix_time headers causes build times to skyrocket. Building a file that includes boost/date_time/posix_time/posix_time.hpp takes almost a minute, removing the header drops the time to less than a second. Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :) }}}" nobody az_sw_dude 1207 "Method ""from_julian_day_number"" (class gregorian_calendar) not documented" date_time Boost 1.51.0 Feature Requests 2007-08-23T10:19:03Z 2012-07-01T17:53:56Z "please could you put the method gregorian_calendar::from_julian_day_number() in the documentation ? library: date_time thanks gizmo" thom_schu@… az_sw_dude 3132 Provide conversions to time_t date_time Feature Requests 2009-06-04T09:23:12Z 2012-07-01T18:11:19Z "Extracted from #889. ==========8<============ Also why no conversions to time_t? It would be nice not to have include the header outside of translation units. :) ==========>8============ Need to provide conversion function from Boost.DateTime types to std::time_t." Andrey Semashev barendgehrels 8183 boost::geometry::intersection on two polygons returns incorrect empty intersection geometry To Be Determined Bugs 2013-02-26T09:24:56Z 2013-03-17T17:47:02Z "Hi The code snippet intersects 2 2D polygons resulting in an empty intersection. I'm including an image of the two polygons and they are overlapping. There may be a problem because the polygons share an overlapping edge? Thanks Matthew Danielsen {{{ polygon_2d triangle2D; { const double triangle2Dcoor[] = {{0.891747, 2.28756}, {0.490911, -1.52549}, {-1.72945, -1.52549}, {0.891747, 2.28756}}; assign(triangle2D, triangle2Dcoor); } polygon_2d box2D; { const double box2Dcoor[] = {{-1.6744, -1.52549}, {-1.70498, -1.52549}, {-1.70052, -1.49155}, {-1.67049, -1.49579}, {-1.6744, -1.52549}}; assign(box2D, box2Dcoor); } boost::geometry::model::multi_polygon< boost::geometry::model::polygon > > intersectionPolygons; boost::geometry::intersection(triangle2D, box2D, intersectionPolygons); assert(intersectionPolygons.size() != 0); // Assert fails }}} " matthewd@… barendgehrels 8366 """Overlay invalid input exception"" (3)" geometry To Be Determined Bugs 2013-04-02T08:19:24Z 2014-11-19T15:14:58Z "Please find below some code that triggers ""Overlay invalid input exception"" (in the last statement of the example). I have a couple of different reproductions, and since I'm not sure if they all share the same root cause, I'm filing them in separate tickets. As always, my polygon type is oriented '''counter-clockwise''' and '''not closed''', my point type is based on '''int'''. This is the data that triggers the exception: {{{ _intPolygon polygon( ""MULTIPOLYGON(((529 998,5337 998,5337 3475,529 3475)))"" ); { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 3314,1734 2054,2934 1670,4140 1754,5340 2072,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 3218,1734 1784,2934 1400,4140 2582,5340 1832,5340 32767,528 32767)))""); polygon -= polygonB; } { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 3218,1734 1784,2934 1400,4140 2582,5340 1832,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 2498,1734 1406,2934 1574,4140 3002,5340 1178,5340 32767,528 32767)))""); polygon -= polygonB; } { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 2498,1734 1406,2934 1574,4140 3002,5340 1178,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 2420,1734 2186,2934 2378,4140 2750,5340 1250,5340 32767,528 32767)))""); polygon -= polygonB; } { _intPolygon const polygonB = _intPolygon(""MULTIPOLYGON(((528 2420,1734 2186,2934 2378,4140 2750,5340 1250,5340 32767,528 32767)))"") ^ _intPolygon(""MULTIPOLYGON(((528 1724,1734 2552,2934 1640,4140 2396,5340 1460,5340 32767,528 32767)))""); polygon -= polygonB; } }}} This is my code that wraps boost::geometry to implement the operators used above: {{{ template template _TPolygon< T > _TPolygon< T >::operator-(Geometry const& geometry) const { // should not be necessary //if( boost::geometry::area(geometry)==0 ) return *this; _TPolygon< T > polygonOut; boost::geometry::difference(*this, geometry, polygonOut); // should not be necessary //boost::geometry::correct( polygonOut ); return polygonOut; } template template _TPolygon& _TPolygon< T >::operator-=(Geometry const& geometry) { // boost::geometry::difference cannot operate in-place // http://lists.boost.org/geometry/2012/02/1796.php *this = *this - geometry; return *this; } template template _TPolygon< T > _TPolygon< T >::operator^(Geometry const& geometry) const { _TPolygon< T > polygonOut; boost::geometry::sym_difference(*this, geometry, polygonOut); // should not be necessary //boost::geometry::correct( polygonOut ); return polygonOut; } }}}" Volker Schöch barendgehrels 8701 wrong empty polygon-linestring intersection with overlapping edges geometry To Be Determined Bugs 2013-06-16T09:21:11Z 2013-08-27T21:04:08Z "The returned intersection between these geometries is empty, although they overlap completely and I would expect the full linestring to be returned: POLYGON((137372 104999998,137372 97499999,67175839 97499999,67175839 104999998)) LINESTRING(399872 104971332,399872 97528663,2899872 97528663,2899872 104971332,5399872 104971332,5399872 97528663,7899872 97528663,7899872 104971332,10399872 104971332,10399872 97528663,12899872 97528663,12899872 104971332,15399872 104971332,15399872 97528663,17899872 97528663,17899872 104971332,20399872 104971332,20399872 97528663,22899872 97528663,22899872 104971332,25399872 104971332,25399872 97528663,27899872 97528663,27899872 104971332,30399872 104971332,30399872 97528663,32899872 97528663,32899872 104971332,35399872 104971332,35399872 97528663,37899872 97528663,37899872 104971332,40399872 104971332,40399872 97528663,42899872 97528663,42899872 104971332,45399872 104971332,45399872 97528663,47899872 97528663,47899872 104971332,50399872 104971332,50399872 97528663,52899872 97528663,52899872 104971332,55399872 104971332,55399872 97528663,57899872 97528663,57899872 104971332,60399872 104971332,60399872 97528663,62899872 97528663,62899872 104971332,65399872 104971332,65399872 97528663,67175839 97528663) If I move one of them slightly, I get a correct intersection instead of an empty set. I'm using double for point coordinates. This issue might be related to #8310 and #8183." aar@… barendgehrels 11580 invalid buffer result geometry To Be Determined Bugs 2015-08-25T10:00:19Z 2016-03-26T15:33:14Z "The following code example produces invalid results. Reducing the distance e.g. from 2.37 to 1 produces correct results. I have tested this code with boost 1.57 and boost 1.59 with the same results. {{{ #include #include namespace bg = boost::geometry; int main() { typedef bg::model::point point; typedef bg::model::polygon 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 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 grown; bg::buffer(poly, grown, distance_strategy, side_strategy, join_strategy, end_strategy, point_strategy); std::cout << bg::wkt(grown) << std::endl; return 0; } }}} The returned shape is: MULTIPOLYGON(((16.39 474.96,16.3842 474.795,16.3669 474.63,16.3382 474.467,16.2982 474.307,16.2471 474.149,16.1851 473.996,16.1126 473.847,16.0299 473.704,15.9374 473.567,15.8355 473.437,15.7248 473.314,15.6058 473.199,15.4791 473.092,15.3453 472.995,15.205 472.908,15.0589 472.83,14.9078 472.763,14.7524 472.706,14.5934 472.66,14.4315 472.626,14.2677 472.603,14.1027 472.591,13.9373 472.591,13.7723 472.603,13.6085 472.626,13.4466 472.66,13.2876 472.706,13.1322 472.763,12.9811 472.83,12.835 472.908,12.6947 472.995,12.5609 473.092,12.4342 473.199,12.3152 473.314,12.2045 473.437,12.1026 473.567,12.0101 473.704,11.9274 473.847,11.8549 473.996,11.7929 474.149,11.7418 474.307,11.7018 474.467,11.6731 474.63,11.6558 474.795,11.65 474.96,11.6558 475.125,11.6731 475.29,11.7018 475.453,11.7418 475.613,11.7929 475.771,11.8549 475.924,11.9274 476.073,12.0101 476.216,12.1026 476.353,12.2045 476.483,12.3152 476.606,12.4342 476.721,12.5609 476.828,12.6947 476.925,12.835 477.012,12.9811 477.09,13.1322 477.157,13.2876 477.214,13.4466 477.26,13.6085 477.294,13.7723 477.317,13.9373 477.329,14.1027 477.329,14.2677 477.317,14.4315 477.294,14.5934 477.26,14.7524 477.214,14.9078 477.157,15.0589 477.09,15.205 477.012,15.3453 476.925,15.4791 476.828,15.6058 476.721,15.7248 476.606,15.8355 476.483,15.9374 476.353,16.0299 476.216,16.1126 476.073,16.1851 475.924,16.2471 475.771,16.2982 475.613,16.3382 475.453,16.3669 475.29,16.3842 475.125,16.39 474.96))) " Marios Visvardis barendgehrels 12125 Another problems performing boolean operations on polygons with shared edges geometry Boost 1.63.0 Bugs 2016-04-13T22:43:43Z 2016-10-28T16:17:05Z "Trying to solve problems with union_ operation on mpolygons with shared edges (https://svn.boost.org/trac/boost/ticket/12118) with help of boost 1.61.0 beta. But instead of getting problems with zero areas, I'm getting really wrong result. For example currentPath[[BR]] MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438))) appended Polygon[[BR]] MULTIPOLYGON(((7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,13.00057315826416015625 -33.85240554809570312500,7.83307075500488281250 -32.98977279663085937500)),((-22.50806808471679687500 -27.92480468750000000000,7.83307075500488281250 -32.98977279663085937500,-14.87041568756103515625 -6.99879980087280273438,-22.50806808471679687500 -27.92480468750000000000))) Union result (same as currentPath, appended Polygon was totally ignored)[[BR]] MULTIPOLYGON(((-5.96064376831054687500 -17.19871711730957031250,7.83307075500488281250 -32.98977279663085937500,8.81292819976806640625 -34.11151504516601562500,19.66869926452636718750 -14.42036247253417968750,-5.96064376831054687500 -17.19871711730957031250)),((-14.87041568756103515625 -6.99879980087280273438,-16.12161636352539062500 -18.30021858215332031250,-5.96064376831054687500 -17.19871711730957031250,-14.87041568756103515625 -6.99879980087280273438)))" ev.mipt@… barendgehrels 13072 boost::geometry::intersection different results for CCW and CW geometry To Be Determined Bugs 2017-06-14T10:57:24Z 2017-06-14T13:13:25Z "Hello,[[BR]] when calculating the intersection between these two polygons the results differ dependent on the orientation (CW vs CCW). {{{ #include #include #include int main(int argc, char* argv[]) { typedef boost::geometry::model::polygon, true, false > boost_polygon_CW_Open; typedef boost::geometry::model::polygon, false, false > boost_polygon_CCW_Open; const std::string strPoly1( ""POLYGON((986.53314901320903 603.61376367962623, 1014.6804499149767 602.74037774442763, 1018.1411735073581 623.97665453539310, 990.14493850604447 624.49725628790509))"" ); const std::string strPoly2( ""POLYGON((986.77183669558929 603.60635741124452, 998.79457181965154 603.23330253835934, 1002.2613711877982 623.79581100129735, 990.30090761267468 624.02156931285253))"" ); boost_polygon_CW_Open p1_cw_open, p2_cw_open; boost::geometry::read_wkt(strPoly1, p1_cw_open); boost::geometry::read_wkt(strPoly2, p2_cw_open); boost::geometry::correct(p1_cw_open); // reverts order of points boost::geometry::correct(p2_cw_open); // reverts order of points std::vector 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 output_ccw; boost::geometry::intersection(p1_ccw_open, p2_ccw_open, output_ccw); // incorrect: output_cw is empty!!! return 0; } }}} " kle@… barendgehrels 13444 boost::geometry::buffer returns only partial result (regression over 1.63.0) geometry To Be Determined Bugs 2018-02-09T10:44:56Z 2018-02-17T17:53:03Z "using boost::geometry::buffer with multilinestring, only 1 of expected 3 polygons are returned. The fix ist to buffer each linestring separately and union_ them into one multipolygon. This also turned out to be much faster. I do not have a simple example, but a rather complex one, which I will attach. Version 1.63.0 returned all 3 polygons, but was also rather slow when compared with the workaround." andre.meyer@… barendgehrels 13522 Invalid empty result using boost::geometry::difference geometry To Be Determined Bugs 2018-04-16T09:43:01Z 2018-05-16T06:21:58Z "Hello, executing the following polygon difference operation sequence produces an obviously incorrect empty result. The first difference produces a (possibliy) valid result with a spike which might be the actual problem. The third difference with the previous result generates an empty result. The intermediate difference is required the reproduce this behaviour. Without it the result of the third difference is correct. Removing the spike from step one also solves the problem. Code to reproduce this: using point_type = boost::geometry::model::d2::point_xy; using polygon = boost::geometry::model::polygon; using multi_polygon = boost::geometry::model::multi_polygon; BoostGeometryBridge::Polygon2d_t Right[3]; BoostGeometryBridge::MultiPolygon2d_t Left[4]; boost::geometry::read_wkt(""MULTIPOLYGON(((0.747399249902131135 -0.974867609298678328,0.744720465461241043 -0.984866128861542012,0.737400169703072983 -0.992186849248596014,0.72740024741975795 -0.994866631198703,0.169444950081761997 -0.994882813404528998,0.156263880981993009 -0.992649068186161054,0.144555091741144004 -0.986196591543298973,0.135626528763234999 -0.976246166252738967,0.0970341390445131069 -0.91515608670535098,0.0527935015388215009 -0.831873652851741974,0.0149278636239085008 -0.745505885364162957,-0.016349202846282801 -0.656539920475841976,-0.0408612872409169006 -0.56547754891590496,-0.0584701351532070993 -0.472832385681689005,-0.0690764281904878985 -0.379126973119241983,-0.0726203441553292944 -0.284889833651171986,-0.0690818944579700972 -0.19065248877542601,-0.058481036857029399 -0.0969464611485150035,-0.0408775628926898033 -0.00430027666216776031,-0.0163707606471800993 0.086763516577464006,0.0149011452653820004 0.17573129555438699,0.0527617733210207981 0.262101259307556012,0.0969975799226773933 0.345386259216249991,0.135586426022915013 0.406478577227274984,0.144514411807557003 0.416429520405822984,0.156222826750318011 0.422882676210660002,0.169403766258661992 0.42511718599825099,0.727359063596658029 0.425133368204076989,0.737359141304932963 0.422454166307816015,0.744679861691986966 0.415133870549649009,0.747359067455327319 0.405136098375181386,0.747329770868999987 1.43513394783313997,2.74732976755064007 1.43524915817017007,2.74708725756255978 5.64524915118547987,-2.74750006237453981 1.25999999251885009,-2.74749997944197011 -4.43500000748115042,0.747500020558034994 -4.43500000604748035,0.747399249902131135 -0.974867609298678328),(-2.49638915854706989 0.152811596222504009,-1.75719536363572004 1.80498971421238008,-1.01782283569549992 1.4741902811305001,-1.75234596398119002 -0.167548384003570999,-1.76762179055725999 -0.173243028570225999,-2.49638915854706989 0.152811596222504009)))"", Left[0]); boost::geometry::read_wkt(""POLYGON((-1.57590744074229994 2.19505211912179998,-2.74750006237453981 1.25999999251885009,-2.74750004134586989 -0.184043917378418992,-1.76796680349592994 -0.184043903114115004,-1.74492840055212994 -0.175455463366190001,-1.00461083616106994 1.47923439340570995,-1.57590744074229994 2.19505211912179998))"", Right[0]); boost::geometry::read_wkt(""POLYGON((2.74708725756255001 5.64524915118547987, 1.48149582377297007 4.63517624723808019, 2.7471454369183701 4.6352491528611397, 2.74708725756255001 5.64524915118547987))"", Right[1]); boost::geometry::read_wkt(""POLYGON((-2.74749997944197011 -4.43500000748115042, -2.74750006237453981 1.25999999251885009, -3.11250006493298015 1.43568817247817004, -3.11249997689355018 -4.61000000763086959, -2.74749997944197011 -4.43500000748115042))"", Right[2]); for(int i = 0; i < 3; i++) { boost::geometry::difference(Left[i], Right[i], Left[i + 1]); } Final result in Left[3] is empty. " lehnert@… barendgehrels 13553 intersection gives wrong result geometry Boost 1.68.0 Bugs 2018-04-30T14:04:02Z 2018-05-16T06:21:26Z "The following polygons result in a wrong intersection: using point_type = boost::geometry::model::d2::point_xy; typedef boost::geometry::model::ring polygon; polygon op1, op2; boost::geometry::read_wkt(""POLYGON((7.7058932076134967 -11.523889618379748,8.0348094747518424 0.63492733448631888,7.7720440433489850 0.63492733448631888, 7.7058932076134967 -11.523889618379748))"", op1); boost::geometry::read_wkt(""POLYGON((2.6206910206017642 -32.773696844382265, 5.5835888947200090 -24.273798818378602, 6.7109368565951772 -20.023839227004206, 7.4191426214038723 -15.773870150408516, 7.7058941612236938 -11.523876267001913, -3.1025600674348395 -11.523582486001384, -3.1025610210450365 -32.773541282571529, 2.6206910206017642 -32.773696844382265))"", op2); std::vector result; boost::geometry::intersection(op1, op2, result); result is equal to op1, while op1 is mostly outside op2." marnix.berg@… bemandawes 5734 possible handle leak in posix implementation copy_file_api filesystem Boost 1.48.0 Bugs 2011-07-26T04:04:07Z 2011-07-26T14:49:21Z "There is possible handle leak in POSIX implementation of function '''copy_file_api'''. {{{ ... if ((infile = ::open(from_p.c_str(), O_RDONLY))< 0) { return false; } struct stat from_stat; if (::stat(from_p.c_str(), &from_stat)!= 0) { return false; } ... }}} if '''::stat''' failed, then function exits without closing '''infile''' handle. This problem exists both in '''v3''' and '''v2''' implementations of filesystem. Also this problem exists in previous releases. " alexey.kutumov@… bemandawes 5850 last_write_time on Windows may not work on SMB2-network-mounted drive filesystem To Be Determined Bugs 2011-08-31T15:22:13Z 2011-10-11T12:21:05Z "Consider the following logical operation against a file on a network-mounted drive served over SMB2: 1. fopen(""r+b"")/fwrite/fclose a file. 2. boost::filesystem::last_write_time(file, some other specific time) 3. fopen(""rb"")/fclose a file. As soon as the file is opened in step 3, it appears that the SMB2/redirector actually closes the file and ""flushes"" its pending write in service of step 1. This has the effect of overwriting the time modification in step 2. I believe this is happening because boost's non-POSIX/Windows implementation of last_write_time uses CreateFile() and asks only for FILE_WRITE_ATTRIBUTES. Using GENERIC_WRITE appears to work correctly. Also note, calling utime() instead of boost::filesystem::last_write_time() works correctly. Please see attached test code demonstrating boost's failure, utime()'s success, and native API workaround. Please feel free to contact me for follow up. Thanks, -Ken" Ken Harris bemandawes 5937 Sun C++ 5.11 Linux compilation errors: operations.cpp filesystem To Be Determined Bugs 2011-09-24T12:46:46Z 2011-09-27T17:59:30Z "CC: Sun C++ 5.11 Linux_i386 2010/08/13 usage: CC [ options ] files. Use 'CC -flags' for details ""libs/filesystem/v3/src/operations.cpp"", line 1760: Error: DT_UNKNOWN is not defined. ""libs/filesystem/v3/src/operations.cpp"", line 1766: Error: DT_DIR is not defined. ""libs/filesystem/v3/src/operations.cpp"", line 1768: Error: DT_REG is not defined. ""libs/filesystem/v3/src/operations.cpp"", line 1770: Error: DT_LNK is not defined. 4 Error(s) detected. ""CC"" -library=stlport4 -xO4 -mt -erroff=%none -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I""."" -c -o ""/home/pal/work/cpp/tmp/boost/bin.v2/libs/filesystem/build/sun/release/address-model-64/link-static/stdlib-sun-stlport/threading-multi/v3/src/operations.o"" ""libs/filesystem/v3/src/operations.cpp""" Peter Loibl bemandawes 6188 boost directory_iterator construct throw segmentation fault filesystem To Be Determined Bugs 2011-12-01T04:13:41Z 2012-01-22T15:50:02Z Hi, if i view content of directory in ubuntu only i get a segmentation fault it allways happents in (/proc) directory. anonymous bemandawes 6638 convert_aux fails while intializing global variable filesystem To Be Determined Bugs 2012-02-29T22:39:27Z 2017-04-26T16:12:09Z "''path_traits.cpp''[[BR]] '''convert_aux''' fails in global scope:[[BR]] Trying to initialize global path variable by concatenating '/' a wide string path w/ narrow string path fails! [[BR]] ""Unhandled exception at 0x0f8bc688 (msvcp100d.dll) in paths.exe: 0xC0000005: Access violation reading location 0x00000000."" [[BR]] If initializing inside main() scope everything works fine. I think this worked as expected in previous version(s) 1.48.. no luck with 1.49 though :( [[BR]] Additional info: WIN 32 and 64 bit, MSVS2010[[BR]] {{{ #include #include using namespace boost::filesystem; path p(L""C:\\TEMP\\""); path q(p / L""wide""); // Works! path r(p / ""narrow""); // Breaks :( int _tmain(int argc, _TCHAR* argv[]) { path p(L""C:\\TEMP\\""); path q(p / L""wide""); // Works! path r(p / ""narrow""); // Works here! std::cout << r.string() << std::endl; return 0; } }}} [[BR]] P.S. If more info is required I will reply here not by email." john doe bemandawes 8388 windows_file_codecvt should be allocated with _NEW_CRT filesystem To Be Determined Bugs 2013-04-04T10:08:14Z 2014-08-02T16:16:04Z Due to a bug in VC libraries, when allocating windows_file_codecvt it should be done with _NEW_CRT instead of new. Otherwise if operator new is overriden in the userland application it would be a crash since windows_file_codecvt is allocated with the user provided operator new and deallocated with delete from the C runtime. pedro.larroy@… bemandawes 8642 Global locale prevents from using Boost.Filesystem in global constructors and destructors filesystem To Be Determined Bugs 2013-06-03T13:06:50Z 2017-03-07T09:17:41Z "The problem appears in particular with Boost.Log. On program termination, Boost.Log may attempt to perform final log file rotation, which involves calling Boost.Filesystem routines (path construction, in particular). But Boost.Filesystem is not usable at this point because its global locale is already destroyed. Boost.Filesystem should remain usable during global constructors and destructors. The global locale should either be embedded into the path object (preferred solution, IMHO) or the library should ensure its availability during these stages. " Andrey Semashev bemandawes 9816 boost::filesystem::is_empty does not work for symbolic links on Windows filesystem To Be Determined Bugs 2014-03-30T10:11:13Z 2015-09-10T13:04:38Z "Hi, I'm using boost::filesystem::is_empty() to check if configuration files I'm using are empty. Due to our software deployment these files are mostly symbolic links created with the Windows 7 internal mklink command. I've used Boost 1.46.1 in the past for this and everything worked fine. Lastly I upgraded to 1.55.0 and found out that is_empty does not work anymore. I at first asked at Stackoverflow for some help: [http://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks Boost::filesystem::is_empty() returns false for Symlinks] I also created a Github project which reproduces the problem: [https://github.com/monsdar/BoostSymLinkError Github - BoostSymLinkError]" Nils Brinkmann bemandawes 9824 boost::filesystem::is_empty() doesn't work with symlinks on Windows filesystem To Be Determined Bugs 2014-04-01T09:17:13Z 2015-09-10T13:03:43Z "See the original information on this problem in this Stackoverflow question: hxxp://stackoverflow.com/questions/22668337/boostfilesystemis-empty-returns-false-for-symlinks The person who reported that problem/asked the question on Stackoverflow also set up a github project that demonstrates the problem: hxxps://github.com/monsdar/BoostSymLinkError Basically, the `filesystem::is_empty()` function doesn't follow a symlink, so it will return false even if the target of the symlink has a length greater than 0. The V2 filesystem library worked for this situation. The difference is that V2 used the `stat()` function in the VC++ library, while the V3 filesystem library uses the Win32 `GetFileAttributesExW()` API. The latter does not follow symlinks and returns a file size of 0 regardless of the size of the symlink target. Attached is a diff for libs/filesystem/src/operations.cpp which uses the `stat()` technique very similar to what was used in filesystem V2. A few differences: - `_wstat()` is used instead of `stat()` to accommodate UNICODE filenames - a bit test using `_S_IFDIR` is used to determine if the path is a directory instead of `S_ISDIR()` because the VC++ library doesn't include a `S_ISDIR()` or `_S_ISDIR()` macro. This patch is only lightly tested (MSVC++ 12.0, 32-bit, on Win7 x64, filenames with ASCII characters only). I'm not sure what the motivations for changing to the `GetFileAttributesExW()` API in filesystem V3 were, so I'm not sure if there's a fundamental flaw in using `_wstat()` that would prevent using it in V3. " michael.burr@… bemandawes 10205 FileSystem runtime error: locale::facet::_S_create_c_locale name not valid filesystem Boost 1.57.0 Bugs 2014-07-16T11:59:58Z 2014-10-29T15:18:26Z "Ok this is still broken (see Ticket #5928). On Solaris 10 (sparc) compile this... #include #include int main (void) { std::cout << boost::filesystem::unique_path(""/some/random/path/%%%%%%%"").c_str() << std::endl; return 0; } linking against system and filesystem I had compiled boost_1_55_0 from the site and built just filesystem and system (because program_options fails to compile with gcc 4.9.0 but thats a separate issue). I created the above example in stage/lib folder and ran.. g++ test.cpp -I../../ -L. -lboost_filesystem -lboost_system Below are the results... bash-3.2$ locale LANG=en_GB.UTF-8 LC_CTYPE=en_GB.ISO8859-1 LC_NUMERIC=en_GB.ISO8859-1 LC_TIME=en_GB.ISO8859-1 LC_COLLATE=en_GB.ISO8859-1 LC_MONETARY=en_GB.ISO8859-1 LC_MESSAGES=C LC_ALL= -bash-3.2$ LC_ALL=en_GB.UTF-8 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort (core dumped) -bash-3.2$ LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort (core dumped) -bash-3.2$ LC_ALL=en_GB.ISO8859-1 LD_LIBRARY_PATH=. ./a.out terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort (core dumped) -bash-3.2$ LC_ALL=C LD_LIBRARY_PATH=. ./a.out /some/random/path/7fff459 This is utterly crippling and renders boost filesystem useless on Solaris 10. " sleary@… bemandawes 10233 create_directories causes invalid read filesystem To Be Determined Bugs 2014-07-23T13:48:27Z 2017-12-01T07:07:32Z "The following code, when run under Valgrind, will report two instances of invalid reads during program close (after main). Tested on Ubuntu Linux x64 12.04 (kernel 3.8.0) with gcc 4.6.3. {{{ #include #include int main() { system(""rm -rf /tmp/test""); // make sure directory doesn't already exist boost::filesystem::create_directories(""/tmp/test""); return 0; } }}} " Itay C bemandawes 10485 heap-use-after-free using C++11 range loop filesystem To Be Determined Bugs 2014-09-09T16:14:17Z 2014-10-26T15:35:40Z "Repro code: {{{ #include #include int main() { boost::filesystem::path dir(""/""); for (char c : dir.filename().string()) printf(""%c\n"", c); } }}} I know if I want to fix it I should store dir.filename().string() in a variable (and it works), but in this case it will either crash application or print garbage. Here's what Clang Address Sanitizer prints: {{{ ================================================================= ==12324==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000ef50 at pc 0x48448a bp 0x7fff08f73990 sp 0x7fff08f73988 READ of size 8 at 0x60300000ef50 thread T0 #0 0x484489 in std::string::size() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716 #1 0x484489 in ~path /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:636 #2 0x484489 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6 #3 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64) #4 0x483f1c in _start (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x483f1c) 0x60300000ef50 is located 0 bytes inside of 26-byte region [0x60300000ef50,0x60300000ef6a) freed by thread T0 here: #0 0x46e7b9 in operator delete(void*) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e7b9) #1 0x4843f2 in std::string::_M_rep() const /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:249 #2 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539 #3 0x4843f2 in ~basic_string /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:539 #4 0x4843f2 in ~path /usr/include/boost/filesystem/path.hpp:55 #5 0x4843f2 in main /run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/main.cpp:6 #6 0x7f0679cd0d64 in __libc_start_main (/lib64/libc.so.6+0x21d64) previously allocated by thread T0 here: #0 0x46e4b9 in operator new(unsigned long) (/run/media/constantine/Space/Boost_1.54.0_Bug_Repro_09.07.2014/Debug/app+0x46e4b9) #1 0x7f067a3411d8 (/lib64/libstdc++.so.6+0xbe1d8) #2 0x9 SUMMARY: AddressSanitizer: heap-use-after-free /usr/bin/../lib/gcc/x86_64-redhat-linux/4.8.3/../../../../include/c++/4.8.3/bits/basic_string.h:716 std::string::size() const Shadow bytes around the buggy address: 0x0c067fff9d90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c067fff9de0: fa fa fa fa fa fa fa fa fa fa[fd]fd fd fd fa fa 0x0c067fff9df0: 00 00 00 02 fa fa 00 00 00 03 fa fa 00 00 00 02 0x0c067fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c067fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==12324==ABORTING }}}" iamvfx@… bemandawes 10900 read_symlink fails to correctly read NTFS junctions filesystem To Be Determined Bugs 2014-12-26T16:16:26Z 2017-09-22T08:59:32Z "''Tested on Windows 7 64-bit.'' NTFS directory junctions are now recognized as a symlink by `is_reparse_point_a_symlink` but `read_symlink` does not correctly handle those ""mount point"" reparse points yet. Among other things this also breaks the `canonical` operation. The `REPARSE_DATA_BUFFER` returned by `DeviceIoControl` needs to be accessed differently for regular symlinks and mount points. See msdn.microsoft.com/en-us/library/ff552012.aspx Accessing the ""!PrintName"" as a symlink typically results in the first two (wide) characters of the path being skipped and generally in undefined behavior. A possible fix would be to add a conditional statement checking `info.rdb.ReparseTag == IO_REPARSE_TAG_MOUNT_POINT` and then amend the `symlink_path.assign` call accordingly (using `info.rdb.MountPointReparseBuffer` instead of `info.rdb.SymbolicLinkReparseBuffer`). In version 1.57.0 the offending code can be found in ''libs/filesystem/src/operations.cpp'' around line 1514." Benjamin Kummer-Hardt bemandawes 2150 Inspect needs to check for missing files inspection script Boost 1.37.0 Feature Requests 2008-07-28T14:51:59Z 2013-01-03T19:10:48Z "Objective: Report missing files early enough to take corrective action before a crisis develops. Include generated doc files in the lists searched for. Design: Top level ""required_files.txt"" points to ""required_files.txt"" in subdirectories. That way the root/required_files.txt only has to be edited when a library is added. See attached file for possible ""required_files.txt"" format." Beman Dawes bemandawes 3965 missing functions last_access_time() and last_status_change_time() filesystem Boost 1.43.0 Feature Requests 2010-02-28T05:35:24Z 2012-04-20T13:03:10Z "In Boost.Filesystem I can find a function: template std::time_t last_write_time(const Path& p); which is corresponding to st_mtime (last modification time) of the stat structure. Within the stat structure, their are also st_atime and st_ctime defined, but there are no corresponding functions. Is there a special reason for that? Couldn't they be added? template std::time_t last_access_time(const Path& p); template std::time_t last_status_change_time(const Path& p); Cheers, Sascha " Sascha Ochsenknecht bemandawes 4494 recursive_directory_iterator throws unexpectedly in the non-throw mode filesystem Boost 1.44.0 Feature Requests 2010-07-30T06:13:15Z 2013-08-31T15:54:02Z "In boost::filesystem v3, while it’s possible to choose a no-throw version of recursive_directory_iterator by passing an boost::system::error_code object to its constructor, like this: boost::system::error_code m_ec; for ( recursive_directory_iterator itr(root, m_ec), end_itr; itr != end_itr; ++itr) However, because in the implementation of the recursive_directory_iterator::increment(), directory_iterator is always constructed with the throw version, it would cause exception throws during the for-loop while accessing folders like \System Volume Information on Windows: void increment() { BOOST_ASSERT(m_imp.get() && ""increment of end recursive_directory_iterator""); m_imp->increment(0); if (m_imp->m_stack.empty()) m_imp.reset(); // done, so make end iterator } Where m_imp is an object of recur_dir_itr_imp: void recur_dir_itr_imp::increment(system::error_code* ec) // ec == 0 means throw on error { … } As it’s not possible to catch this exception within the for-loop and continue the loop, it greatly limits the use of recursive_directory_iterator. With a rough check, V2 does not seem to have this problem. it's preferred that the directory_iterator to behave the same as recursive_directory_iterator in this case. " ttan@… bemandawes 5896 Range directory iterators filesystem To Be Determined Feature Requests 2011-09-13T22:42:39Z 2012-04-19T15:26:00Z "With C++11 now finalized as a standard, and compilers being more compliant every day, it makes sense to have range-based versions of the directory_iterator classes. This would make it much easier to use the range-based for loop, as well as Boost.Range functionality. Basically, it could just be a couple of helper functions that create a boost::iterator_range instance." jmckesson@… bemandawes 6018 Add touch() and create_file() functions filesystem To Be Determined Feature Requests 2011-10-13T12:38:26Z 2011-10-13T12:38:51Z "A function with the functionality of the POSIX touch utility would be a great convenience. It meets both the need to update times and the need to create a file. OTOH, it is a bit of a mishmash of logically separate features. Maybe what is really needed is a create_file() function that errors if the file already exists and a touch() function that errors if the file doesn't exist. Alternatively, both could return a bool, true if successful, and not consider it an error if the file, respectfully, already/doesn't exist. " Beman Dawes bemandawes 6521 Directory listing using C++11 range-based for loops filesystem To Be Determined Feature Requests 2012-02-04T18:15:21Z 2017-06-13T14:11:26Z "I have written a simple 'container' class for a directory, 'containing' all of its subdirectories: {{{ namespace boost{ namespace filesystem{ class directory{ path p_; public: inline directory(path p):p_(p){ return; } directory_iterator begin(){ return directory_iterator(p_); } directory_iterator end(){ return directory_iterator(); } }; } } }}} so that that range-based for loop can be used: {{{ for(auto i:directory(""/home"")){ ... } }}}" mustrumr97@… bemandawes 10078 Incomplete API with respect to file related dates (cration, modification, access) filesystem To Be Determined Feature Requests 2014-05-29T09:38:36Z 2014-05-29T12:27:29Z "The following features are missing: - read file's creation date - read file's last access date - read file's creation date with a precision higher than seconds - read file's last access date with a precision higher than seconds - read file's last access date with a precision higher than seconds - allow to detect capabilities of the underlying filesystem (e.g. support for creation and last access date that are not supported by all systems, or finding out date precision supported by the current filesystem) Possible implementation notes: - How to get high precision file date on Linux http://stackoverflow.com/questions/13382695/how-to-get-last-modification-time-of-a-file-with-epoch-time-format-precision-mi - How to get high precision file date on Windows http://msdn.microsoft.com/en-us/library/aa364946.aspx Example of current use of this feature in existing applications: ls --full-time " David Lastovicka bemandawes 11663 No way to query file extension without allocating memory filesystem To Be Determined Feature Requests 2015-09-17T06:44:37Z 2016-09-09T18:14:22Z "the function .extension() returns an fs::path, containing a fresh string that contains the extension. On certain library implementations that don't implement the SSO -- or, I guess, for files with very long extensions -- there will be a memory allocation each time the function is called. That means that for solutions implementing search-by-extension such as is written in: http://stackoverflow.com/questions/11140483/how-to-get-list-of-files-with-a-specific-extension-in-a-given-folder there could be hundreds of memory allocations for just iterating a directory structure. IMO, there really shouldn't be. I propose adding the function bool path::has_extension(string const&) which can compare the extension in a memory-friendly way." matthew.chaplain@… bemandawes 2066 Inspect needs to review generated doc files too inspection script Boost 1.36.0 Tasks 2008-07-03T11:16:35Z 2013-01-03T19:11:23Z "Inspect needs to run on release snapshot so that it is looking at the generated doc files too. But it also needs to be modified so that if it is running on a snapshot (or other cases where svn info doesn't work), the revision number and URL are picked up from somewhere else. Maybe it would be easier to copy the files from the release snapshot into a release working copy so that inspect will work as it is not." Beman Dawes burbelgruff 5745 Use native typeof support for Oracle Solaris Studio C++ compiler typeof Boost 1.48.0 Feature Requests 2011-08-01T14:51:58Z 2011-08-09T09:50:47Z "Oracle Solaris Studio (former !SunStudio) C++ compiler supports native typeof since version 5.9. At the same time, support for typeof emulation is not so good (many compilation errors). It would be beneficial for Boost users if Boost used native typeof instead of emulation. Here is proposed patch: {{{ *** boost/typeof/typeof.hpp 2011-08-01 18:46:33.411406362 +0400 --- boost/typeof/typeof.hpp.new 2011-08-01 18:46:43.680746049 +0400 *************** *** 155,160 **** --- 155,176 ---- # else # error native typeof is not supported # endif + #elif defined(__SUNPRO_CC) + # if (__SUNPRO_CC < 0x590 ) + # ifdef BOOST_TYPEOF_NATIVE + # error native typeof is not supported + # endif + # ifndef BOOST_TYPEOF_EMULATION + # define BOOST_TYPEOF_EMULATION + # endif + # else + # ifndef BOOST_TYPEOF_EMULATION + # ifndef BOOST_TYPEOF_NATIVE + # define BOOST_TYPEOF_NATIVE + # endif + # define BOOST_TYPEOF_KEYWORD __typeof__ + # endif + # endif #else //unknown compiler # ifndef BOOST_TYPEOF_NATIVE # ifndef BOOST_TYPEOF_EMULATION }}}" Maxim Kartashev chris_kohlhoff 2875 Windows: ip::tcp::acceptor::local_endpoint() cannot be used in socket connect asio To Be Determined Feature Requests 2009-03-20T06:19:50Z 2009-04-09T13:05:18Z "On linux the local_endpoint() function returns an endpoint similar to 0.0.0.0:1234. A socket which is given this endpoint to connect to will connect successfully. A similar endpoint is returned on Windows, however the socket connection is not successful. I am currently working around this problem by inserting loopback as the address to connect to. For the sake of consistency between platforms it may be worthwhile including a similar substitution within the socket's connect operation if 0.0.0.0 is detected." Benjamin Carlyle cornedbee 9991 WConversion issue in json_parser_write.hpp property_tree To Be Determined Bugs 2014-05-02T06:21:11Z 2016-02-10T13:04:37Z "File Name: 1_54_0/boost/property_tree/detail/json_parser_write.hpp There is a severe problem with the -Wconversion issue in the json_parser_write.hpp Problematic code: else { const char *hexdigits = ""0123456789ABCDEF""; typedef typename make_unsigned::type UCh; unsigned long u = (std::min)(static_cast( static_cast(*b)), 0xFFFFul); ''' int d1 = u / 4096; u -= d1 * 4096; int d2 = u / 256; u -= d2 * 256; int d3 = u / 16; u -= d3 * 16; int d4 = u;''' result += Ch('\\'); result += Ch('u'); result += Ch(hexdigits[d1]); result += Ch(hexdigits[d2]); result += Ch(hexdigits[d3]); result += Ch(hexdigits[d4]); } Either we need to do explicit static cast to suppress the Conversion Warning. When we turn on the -Wconversion as well as -Werror both together, which is good practice for production ready code. compiler Just dont allow this to compile. the above need to be fixed." abhi.california@… cornedbee 10188 Loses floating point precision on round trip property_tree To Be Determined Bugs 2014-07-10T13:54:12Z 2015-01-23T12:25:23Z "ptrees stream_translator uses a precision of std::numeric_limits::digits10 + 1 when converting floating point values. This is not always enough, and a more correct value would be digits10+2 or max_digits10 (c++11 only). See ticket:9177 for a similar issue. The attached test produces the following output pre-patch: {{{ in : -1.8312345000098765e-08 out: -1.8312345000098762e-08 Wrong }}} and after patch: {{{ in : -1.8312345000098765e-08 out: -1.8312345000098765e-08 Right }}}" Magne OEstlyngen cornedbee 11502 narrow_encoding: -Wtype-limits warning is reported property_tree To Be Determined Bugs 2015-07-26T12:28:26Z 2016-02-10T12:51:31Z "-Wtype-limit is reported on this assert: char to_internal_trivial(char c) const { assert(c <= 0x7f); <=== Type limit return c; } " davido cornedbee 5658 how to get rid of nasty compiler warning in boost/property_tree/detail/rapidxml.hpp property_tree To Be Determined Tasks 2011-06-29T07:39:25Z 2014-02-14T15:10:46Z "compiling e.g libs/graph/src/graphml.cpp warns ... {{{ /boost/property_tree/detail/rapidxml.hpp: In function `size_t boost::property_t ree::detail::rapidxml::internal::get_index(Ch) [with Ch = char]': ./boost/property_tree/detail/rapidxml.hpp:1413: instantiated from `static unsi gned char boost::property_tree::detail::rapidxml::xml_document::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::skip(Ch*&) [with Stop Pred = boost::property_tree::detail::rapidxml::xml_document::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::parse(Ch*) [with int Flags = 3072, Ch = char]' ./boost/property_tree/detail/xml_parser_read_rapidxml.hpp:116: instantiated fr om `void boost::property_tree::xml_parser::read_xml_internal(std::basic_istream< typename Ptree::key_type::value_type, std::char_traits >&, Ptree&, int, const std::string&) [with Ptree = boost::property_ tree::basic_ptree >]' ./boost/property_tree/xml_parser.hpp:52: instantiated from `void boost::proper ty_tree::xml_parser::read_xml(std::basic_istream >&, Ptree&, int) [ with Ptree = boost::property_tree::ptree]' libs/graph/src/graphml.cpp:49: instantiated from here ./boost/property_tree/detail/rapidxml.hpp:317: warning: comparison is always fal se due to limited range of data type }}} Caused by the template: {{{ template inline size_t get_index(const Ch c) { // If not ASCII char, its sematic is same as plain 'z' if (c > 255) { return 'z'; } return c; } }}} How to avoid ? Just specify additionally a user defined implementation of get_index for the ""char"" type : {{{ inline size_t get_index(const char c) { return c; } template inline size_t get_index(const Ch c) { // If not ASCII char, its sematic is same as plain 'z' if (c > 255) { return 'z'; } return c; } }}} I checked the code size (using gcc4.0) : same and the difference of the ASM code: ""same"" {{{ 14972c14972 < cmpq (%r15), %rdi --- > cmpq %rdi, (%r15) 14974c14974 < jae .L3637 --- > jbe .L3637 15002c15002 < cmpq -16(%rsi), %rdi --- > cmpq %rdi, -16(%rsi) 15004c15004 < jae .L3643 --- > jbe .L3643 15017c15017 < cmpq -16(%rdx), %rdi --- > cmpq %rdi, -16(%rdx) 15019c15019 < jb .L3796 --- > ja .L3796 15487c15487 --- }}}" Dieter Stach danieljames 8565 Lists in admonitions quickbook To Be Determined Bugs 2013-05-13T11:12:38Z 2013-09-29T11:35:22Z "It seems not to be possible to include lists in admonitions. E.g. the following won't work, meaning no list will be displayed but just the stars as characters: [note Some text for my note * first point I want to note * second point I want to note ]" thomas.moeck@… danieljames 1558 Optional separate compilation unordered To Be Determined Feature Requests 2008-01-06T18:41:53Z 2009-02-21T18:17:31Z There are some parts of Boost.Unordered that could be compiled into a library file. Provide an option to do this. Daniel James danieljames 1979 More example hash functions unordered To Be Determined Feature Requests 2008-06-01T10:17:27Z 2009-02-21T18:17:46Z Daniel James danieljames 2448 syntax highlighting for code in documentation or website Documentation Website 1.X Feature Requests 2008-10-29T19:56:48Z 2009-02-21T17:15:22Z "In Boost documentation there are a lot of code examples which it would be better if it will be with syntax highlighting to be more readable. " hagai26@… danieljames 8545 Can quickbook support parts and chapters as well as sections? quickbook To Be Determined Feature Requests 2013-05-03T15:56:14Z 2013-05-06T16:38:17Z "Currently the only ""top level"" structure supported is the section, but it would be very useful for longer documents have to have support for chapters, parts and appendixes as well. As far as I know these can't be implemented as templates as these get ... wrapped around them even when they're block templates." John Maddock danieljames 1175 Document quickbook's (lack of) unicode support. quickbook To Be Determined Tasks 2007-08-13T11:23:21Z 2009-06-06T13:47:40Z See http://tinyurl.com/35j57v Joel de Guzman danieljames 1279 Make sure multiple #import of a file imports the file only once. quickbook To Be Determined Tasks 2007-09-24T06:37:48Z 2013-09-29T11:21:32Z Joel de Guzman danieljames 1487 Update the writing documentation instructions Documentation To Be Determined Tasks 2007-11-30T20:01:35Z 2010-06-07T22:40:00Z The documentation (http://www.boost.org/more/writingdoc/structure.html) needs to updated and probably should be moved to the new site. Daniel James david.bellot 4442 Simple implementation of operator * for matrices with 0 complexity uBLAS To Be Determined Patches 2010-07-15T22:47:25Z 2013-08-01T12:18:50Z "The following is a simple implementation of operator * for matrix-matrix and matrix-vector which simply forwards to the existing prod() implementation. Since nested products A * B * C can't work yet, it does a compile time check to make sure this isn't occuring. See attached patch and test file. Note that this also has patched changes for ticket #4441 built in " Jesse Perla eric_niebler 3936 [xpressive] stack overflow. xpressive Boost 1.43.0 Bugs 2010-02-16T14:56:20Z 2010-02-17T00:06:35Z "The following simple program fires a stack overflow exception in xpressive. It's seems too simple to be causing such problems. {{{#include ""stdafx.h"" #include #include using namespace boost::xpressive; int _tmain(int argc, _TCHAR* argv[]) { sregex rx = ~(set='{', '}', ','); sregex rx2 = +rx; std::string s(10000, 'a'); regex_search(s, rx2); return 0; }}}} I'm using MSVC 2005. The problem only occurs if the string is large." shewitt.au@… eric_niebler 6992 accumulator's median feature skips 1st two data points. accumulator To Be Determined Bugs 2012-06-16T01:10:15Z 2016-12-14T11:44:04Z "Hi, I used accumulator's median feature to calculate mean/median of input data. I also used armadillo library's mean/median. The mean from two libraries always agree. However the medians don't. I tried to give 1,2,3,4,5 input data to the program. and found accumulator's median outputs 0 if the number of input data is 1 or 2. It starts to output non-zero median if given more than 2 data points however, first two data points are not used. Please check what is going on. Thanks, yu" polyactis@… eric_niebler 3519 It should be possible to use consts as external placeholder variables. xpressive To Be Determined Feature Requests 2009-10-12T15:26:05Z 2010-10-06T18:18:53Z "The right-and-side of placeholder let-expressions are not declared as const, so common use-cases like: {{{ placeholder _i; smatch what; what.let(_i = 1); }}} or: {{{ placeholder _p; smatch what; what.let(_p = this); }}} fail to compile. It would be nice to have some way to specify a placeholder for non-mutable data. Perhaps: {{{ placeholder _i; }}} (suggested by Eric Niebler) " ami.ganguli@… eric_niebler 4704 Support for multicapture and balancing groups xpressive To Be Determined Feature Requests 2010-10-03T09:05:25Z 2017-06-29T18:58:58Z "Feature request ticked to jog Eric Nieblers memory to take a look at some code. I've added support for multicapture and balancing groups to Boost::Xpressive. Syntax for pop capture: dynamic: (?P<-name>stuff)[[BR]] static: (name -= stuff) Syntax for capture conditional: dynamic: (?P(name)stuff)[[BR]] static: (name &= stuff) The changes are in the vault and can be found here: http://tinyurl.com/3aak7mp It can be unpacked against trunk from 2010-10-02 or the 1.44.0 release. I've run the dynamic regression tests without errors and I have added some tests for the new functionality. The code it only tested on Visual Studio 2010 since I don't have access to any other compiler. Erik Rydgren " erik@… eric_niebler 6891 Add extension point to define how expressions are created from operators proto To Be Determined Feature Requests 2012-05-12T16:15:55Z 2012-06-06T17:39:53Z "As discussed here: It would be nice to add a mechanism to allow to define what the operator overloads created by Proto will do. Unlike other functions where a Proto-based library can construct nodes the way it wishes, there is no control and what the built-in C++ operators do." Mathias Gaunard eric_niebler 4668 Conditions for operator overload in Proto (documentation) proto To Be Determined Tasks 2010-09-21T20:00:16Z 2010-10-06T18:18:11Z "Taken from this thread in boost-users: http://lists.boost.org/boost-users/2010/09/62747.php This explanation by Thomas Heller would make a good section for the proto documentation: {{{ In order for a proto overload to be created the following conditions must be true: 1) the operands must be in a compatible domain 2) the left hand operand and the right hand operand must match the grammar specified in the domain 3) the resulting expression must match the grammar specified in the domain. }}} To illustrate what this means, this minimalistic example might be useful, too: This grammar {{{ proto::plus, proto::terminal > }}} used in a domain would not allow {{{ i + i; }}} with i being an int-terminal. " Roland Bock glenfe 12880 Alignment information @ PP time align Boost 1.65.0 Feature Requests 2017-03-01T14:42:25Z 2017-03-03T13:37:23Z "Please add a macro that can be used for selective compilation based on the guaranteed alignment of the default allocator, i.e. something like: https://bitbucket.org/eigen/eigen/src/d4e10456d28275c27f417efc119024749c979b7e/Eigen/src/Core/util/Memory.h" Domagoj Šarić guwi17 2692 No concepts supporting the idea of dense uBLAS To Be Determined Feature Requests 2009-01-28T20:51:45Z 2009-06-18T08:01:37Z "data() returns a reference to a Storage. However, nowhere in the concepts is a statement saying that &m.data()[0] must to be the address of the first element of the linearly stored data in the Storage. The adjective ""dense"" is used all over, but nowhere is this term given any operational guarantees. Without such guarantees, all the interfaces in, say, the numerics::binding libraries are being built on sand. Related to this is that nothing requires unbounded_array::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. The basic (and inadequate) change is the sprinkling around of the word dense and the phrase ""strict linear order"". Instead you need to explicitly says things like value_type is T and &v[i+j] == &v[i]+j (for reasonable i+j)." dougrm@… guwi17 3396 add a sparse_view class that wraps pre-allocated data into a matrix expression uBLAS Boost 1.42.0 Feature Requests 2009-09-03T20:16:06Z 2009-10-06T23:13:48Z "Provide a way to use ublas with pre-allocated data. Implement a matrix view of a CRS matrix as proof of concept. Details: * given 3 arrays: row pointers, column indices, values (http://www.netlib.org/utk/papers/templates/node90.html) * provide a wrapper that fulfills the immutable part of the matrix expression Further tasks: * split the current matrix and vector concepts into immutable and mutable parts in order to gain a ""read-only view"" concept and a full featured ""expression"" concept * improve traits mechanism and apply it where possible to automatically see a fixed size C-array as vector view or matrix view * add necessary tests " Gunter guwi17 4033 optimized matrix products uBLAS Boost 1.43.0 Patches 2010-03-22T21:38:27Z 2010-03-29T06:58:56Z "proposal from Jörn Ungermann: '''Abstract''' The (lacking) performance of sparse-matrix products was quite often noted on this list. Currently there are several functions which implement matrix products. Each is efficient under certain conditions only and some of them are not even documented. I think it important for users to have one (near-)optimal function only. The attached file contains an improved axpy_prod that matches the performance of ""prod"", ""axpy_prod"" and ""sparse_prod"" and is thereby optimal for all matrix types. '''Details''' The optimal choice of kernel for a matrix product depends on the properties of all involved matrices. The current implementations specialize only on the type of target matrix. By also determining the kernel depending on the source matrices, one can choose the most efficient kernel. My aim was to create a single function to match the performance of prod, axpy_prod and sparse_prod for all combinations of compressed_matrix/matrix and column/row-majority. The other matrix types should also be handled efficiently by my product, too, but I did check it only spuriously, as it should be obvious that those types are more suited for matrix setup, not for actual calculation. My axpy_prod implementation (called axpy_prod2 in the attached file) does not offer support for the undocumented triangular_expression stuff contained in the original axpy_prod, which however seems to be buggy in the current code for dense matrices. The kernels are largely based on existing kernels with one or two new ones being thrown in. They are as abstract as possible to handle arbitrary expressions efficiently. Specializing, e.g. directly on compressed_matrix would give another very significant performance boost, but also many more additional kernels, possibly more than could be maintained, especially as the transposedness might have to be handled explicitly, too. It would be very nice, if someone could rewrite prod/prec_prod to handle matrix products in the same way as my axpy_prod2 does, but I did not look deep enough into the expression-templates to do this myself or to even know if this were possible. In fact, I'd propose to have two sets of interfaces: 1) One convenient one, possibly compromising efficiency [[BR]] 2) One modeled closely after C-BLAS, delivering utmost efficiency. The latter one could then be *very easily* overloaded by the numeric bindings for dense matrices. I added a possible generic implementation for a gemm call that could be trivially overloaded for dense matrices and forwarded to, e.g., ATLAS numeric bindings. If one could achieve the same efficiency and automatic (i.e. by including a header) coupling to numeric bindings using only *one* interface, I'd prefer that naturally. However currently, we have not just two, but too many product functions (prod, prec_prod, axpy_prod, sparse_prod, opb_prod, block_prod). The following table gives the result for all 64 combinations of compressed_matrix/matrix and row/column-majorities for the three involved in this case 2000x2000 matrices. com_rm is a compressed_matrix of row_major type. [[BR]] den_cm is a matrix of column_major type. [[BR]] The  4th column indicates the used kernel. [[BR]] The  5th column gives the runtime for axpy_prod2  ( clock()/1000 ) [[BR]] The  6th column gives the runtime for sparse_prod ( clock()/1000 ) [[BR]] The  7th column gives the runtime for axpy_prod   ( clock()/1000 ) [[BR]] The  8th column gives the runtime for prod        ( clock()/1000 ) [[BR]] The 10th column gives the speedup of axpy_prod2 compared to sparse_prod. [[BR]] The 11th column gives the speedup of axpy_prod2 compared to axpy_prod. [[BR]] The 12th column gives the speedup of axpy_prod2 compared to prod. Larger matrix sizes result in prohibitive runtimes for the ""slow"" products, but can be used to analyse pure-sparse products. The runtime shall be taken only qualitatively. One can see that the only cases where the new implementation is slower are of relatively small runtime, so it may be negligible. sparse_prod uses an optimization that is very efficient if the target matrix has few off-diagonal elements, but is very inefficient if it does. The results will therefore vary depending on the test matrices. It is also obvious to see, why some people complain about product performance, as especially axpy_prod and prod are sometimes ridiculously slow for sparse matrices and sparse_prod does not seem to be documented in the special products section. My favorite case is ""com_cm, com_cm, den_rm"" one, which actually occurred in the diagnostics part of our application and was the reason why we started looking into this topic." Gunter guwi17 1915 Nested matrix products with transposes causes compiler to complain error: invalid application of ‘sizeof’ uBLAS To Be Determined Support Requests 2008-05-14T05:52:05Z 2008-05-14T21:56:28Z "When using ublas, a pair of nested products will cause the compiler to complain if there is a `trans` on any of the operands. For example: {{{ #!cpp using namespace boost::numeric::ublas; matrix A(3,3), B(3,3), C(3,3); prod(prod(A,B),trans(C)); // fails prod(prod(trans(A),B),C); // fails prod(prod(A,trans(B)),C); // fails prod(prod(A,B),C); // OK }}} The compiler produces the following error message: {{{ /opt/local/include/boost/numeric/ublas/matrix_expression.hpp: In function ‘typename boost::numeric::ublas::matrix_matrix_binary_traits::result_type boost::numeric::ublas::prod(const boost::numeric::ublas::matrix_expression&, const boost::numeric::ublas::matrix_expression&) [with E1 = boost::numeric::ublas::matrix_matrix_binary, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::matrix, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::matrix_matrix_prod >, E2 = boost::numeric::ublas::matrix_unary2, boost::numeric::ublas::unbounded_array > >, boost::numeric::ublas::scalar_identity >]’: 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’ }}}" Leo Singer jbosch 6545 boost:::python doesn't recognize std::shared_ptr python USE GITHUB To Be Determined Bugs 2012-02-11T14:03:12Z 2015-09-18T07:17:12Z boost::python specially handles boost::shared_ptr, but special handling is also needed for std::shared_ptr Neal Becker jewillco 3077 Reverse iterator compile-time bug in multi_array multi_array Boost 1.40.0 Bugs 2009-05-25T10:47:28Z 2010-06-08T22:51:47Z "I'm having some trouble iterating over a 2-dimensional multi_array in reverse order. I'm using boost 1.38 with gcc-4.2.4 and the following code won't compile with the error given below: {{{ #include template< typename It > void iterate_over( It begin, It end ) { while( end != begin ) { begin->end() - begin->begin(); ++begin; } } void test() { boost::multi_array< double, 2 > m; iterate_over( m.begin(), m.end() ); // works fine iterate_over( m.rbegin(), m.rend() ); // causes error } }}} This looks to me like a bug in the implementation of the reverse iterator for multi_array. Am I wrong? It is only a problem when iterator::operator-> is used. The (*begin). notation works fine. /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp: In static member function ‘static typename boost::mpl::if_, Pointer, boost::detail::operator_arrow_proxy >::type boost::detail::operator_arrow_result::make(Reference) [with ValueType = boost::multi_array >, Reference = boost::detail::multi_array::sub_array, Pointer = boost::multi_array >*]’: /home/john/Dev/ThirdParty/boost/boost_1_38_0/boost/iterator/iterator_facade.hpp:648: instantiated from ‘typename boost::detail::operator_arrow_result::value_type, Reference, typename boost::detail::iterator_facade_types::pointer>::type boost::iterator_facade::operator->() const [with Derived = boost::reverse_iterator, boost::detail::multi_array::sub_array > >, Value = boost::multi_array >, CategoryOrTraversal = boost::detail::iterator_category_with_traversal, Reference = boost::detail::multi_array::sub_array, Difference = long int]’ src/sandbox/seqan_sandbox.cpp:12: instantiated from ‘void iterate_over(It, It) [with It = boost::reverse_iterator, boost::detail::multi_array::sub_array > >]’ 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*)’ " John Reid jewillco 5636 BGL isomorphism vertex invariant interface change graph To Be Determined Feature Requests 2011-06-23T22:48:35Z 2011-07-29T02:26:06Z "(This is the last isomorphism ticket I think. :-)) I have one more suggestion about how to handle vertex invariants. To determine whether `u` and `v` should be considered equivalent by the isomorphism, instead of providing two functors `f` and `g`, calling `f(u)` and `g(v)` to get a pair of integers, and finally comparing the result, I think it would be cleaner to have a ""binary"" predicate `p` which would be called as `p(u,v)`. (In reality of course you'd probably want to have it receive `g1` and `g2` as well, so it'd really be a 4-arg function.) This should also let you get rid of the `vertex_max_invariant` parameter perhaps. I'm not sure of how this would impact the performance or how you'd do sorting, but you could probably do it by doing an N^2 traversal and recording for each `u` in `g1` how many `v`s in `g2` are considered equivalent. This is a bit different from what you're doing now, I think. (The benefit of this would be it becomes easier to impose extra conditions on the isomorphism. Instead of figuring out how to encode everything into an integer -- and worrying about the fact that you make an array of size `vertex_max_invariant`, so you can't even use all that much of that size -- you can just test it directly.)" Evan Driscoll jhunold 6893 Inaccurate Radians/Degrees conversion units To Be Determined Bugs 2012-05-13T10:19:17Z 2018-07-08T16:19:39Z "LS, The conversion from angles in degrees to radians currently uses a conversion factor of 6.28318530718/360. (File: boost\units\base_units\angle\degree.hpp), which equals 0.0174532925199444444... This is unnecessarily inaccurate (only 14 significant digits are correct) and gives problems in my application - the actual value reads: 0.017453292519943295769236907684886127134428718885417... Using this value improves conversion accuracy significantly. Please consider using this more accurate value. Alternatively, the use of boost::math::constants could be considered, making the factor: boost::math::constants::pi()/180.0 which works fine as well. " pieterb@… jking 2801 gregorian_calendar_base: incorrectly assumes that sizeof(int)==sizeof(long) date_time To Be Determined Bugs 2009-02-25T20:54:04Z 2018-01-18T14:19:55Z "boost::date_time::gregorian_calendar_base() returns an int, but uses several local variables of type unsigned long, leading to warnings about possible loss of data when converting from unsigned long to int on 64 bit OSes that use the LP64 data model. Here is a rewrite of the function that generates no warnings when compiled with -Wshorten-64-to-32 under GCC 4.0.1 on Mac OS 10.5: {{{ template BOOST_DATE_TIME_INLINE int gregorian_calendar_base::week_number(const ymd_type& ymd) { date_int_type_ julianbegin = julian_day_number(ymd_type(ymd.year,1,1)); date_int_type_ juliantoday = julian_day_number(ymd); date_int_type_ day = (julianbegin + 3) % 7; date_int_type_ week = (juliantoday + day - julianbegin + 4)/7; if ((week >= 1) && (week <= 52)) { return static_cast(week); } if ((week == 53)) { if((day==6) ||(day == 5 && is_leap_year(ymd.year))) { return static_cast(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(ymd.year-1),1,1)); juliantoday = julian_day_number(ymd); day = (julianbegin + 3) % 7; week = (juliantoday + day - julianbegin + 4)/7; return static_cast(week); } return static_cast(week); //not reachable -- well except if day == 5 and is_leap_year != true } }}} " pelee@… jking 10285 local_time is not monotonic date_time To Be Determined Bugs 2014-08-01T08:03:44Z 2018-01-06T15:43:11Z "The following snippet seems to generate non monotonic local_date. I'm using boost 1.55 on linux. #include #include int main() { const boost::local_time::time_zone_ptr theTimeZone( new boost::local_time::posix_time_zone( ""CET+01CEST+01,M3.5.0/02:00,M10.5.0/03:00"") ); boost::local_time::local_date_time myOldValue( boost::local_time::local_microsec_clock::local_time(theTimeZone)); for (size_t i = 0; ; ++i) { const boost::local_time::local_date_time myLocalTime = boost::local_time::local_microsec_clock::local_time(theTimeZone); if (myLocalTime < myOldValue) { std::cout << myOldValue << std::endl; std::cout << myLocalTime << std::endl; std::cout << boost::local_time::local_microsec_clock::local_time(theTimeZone) << std::endl; std::cout << ""===================="" << std::endl; } myOldValue = myLocalTime; } } As you can see the program is not supposed to print anything ever, however this is what I'm getting: 2014-Jul-31 00:24:56.005625 CEST 2014-Jul-31 00:24:55.005631 CEST <== 1 second back 2014-Jul-31 00:24:56.005946 CEST ==================== 2014-Jul-31 00:24:58.005625 CEST 2014-Jul-31 00:24:57.005629 CEST <== 1 second back 2014-Jul-31 00:24:58.005824 CEST ==================== 2014-Jul-31 00:25:02.005624 CEST 2014-Jul-31 00:25:01.005628 CEST <== 1 second back 2014-Jul-31 00:25:02.005838 CEST ==================== 2014-Jul-31 00:25:04.005625 CEST 2014-Jul-31 00:25:03.005630 CEST <== 1 second back 2014-Jul-31 00:25:04.005826 CEST ==================== 2014-Jul-31 00:25:06.005624 CEST 2014-Jul-31 00:25:05.005633 CEST <== 1 second back 2014-Jul-31 00:25:06.005853 CEST ==================== 2014-Jul-31 00:25:07.005625 CEST 2014-Jul-31 00:25:06.005631 CEST <== 1 second back 2014-Jul-31 00:25:07.005846 CEST ==================== 2014-Jul-31 00:25:12.005625 CEST 2014-Jul-31 00:25:11.005631 CEST <== 1 second back 2014-Jul-31 00:25:12.005822 CEST ==================== as you can see when the local_date is near 0.005631 second fraction it goes back of one second and then forward again on the following call. " Gaetano Mendola jking 11067 boost::gregorian::date_iterator missing postfix operators ++ and -- date_time To Be Determined Feature Requests 2015-03-03T16:29:10Z 2017-12-28T13:35:12Z "/* Consider the following (somewhat canonical) code snippet */ { std::vector dates(count); auto dt_i = dates.begin(); boost::gregorian::month_iterator m_i(some_start_date, 1); while (dt_i != dts.end()) *dt_i++ = *m_i++; /* this will call prefix ++ operator on m_i leading to subtle bug */ }" dkochin@… johnmaddock 10103 setprecision(0) does displays too many digits of a float128 multiprecision To Be Determined Bugs 2014-06-07T12:38:29Z 2015-10-14T14:40:49Z "setprecision(0) is not honored for float128. Compare the display of a double and a float128 (default and fixed): {{{ 0.1 0.123400000000000000000000000000000006 0 0.123400000000000000000000000000000006 }}} This is produced with {{{ #include #include int main() { double x = 0.1234; boost::multiprecision::float128 y = 0.1234Q; std::cout << std::setprecision(0) << x << "" "" << y << ""\n""; std::cout << std::fixed << x << "" "" << y << ""\n""; } }}} " Charles Karney johnmaddock 3408 gamma distribution's quantile performance math Boost 1.41.0 Tasks 2009-09-06T18:50:32Z 2009-10-06T17:13:28Z "Hi there, I have created a test which times the performance of boost::math::quantile( ... ) when using a gamma distribution. I ran it against source code we use here at work, for ages. It can be found here: http://people.sc.fsu.edu/~burkardt/cpp_src/dcdflib/dcdflib.html The old source code is about 2x times faster than the boost version. MS Visual Studio 2005: boost: 35.4sec att_bell:19sec Intel 11.1: boost: 21.4sec att_bell: 11.2sec Question is if there is a way to incorporate such a function into boost::math? As far, as I can tell the results are almost identical. Here the code: #include #include #include double min_mean = 2000; // 2,000 double max_mean = 500000000; //500,000,000 double min_std = 10000; // 10,000 double max_std = 100000000; // 100,000,000 double min_max = 600000000; // 600,000,000 double max_max = 1000000000; // 1,000,000,000 const std::size_t max_year = 5000000; // 5,000,000 const double right = 0.999; const double left = 0.001; inline double get_rand() { return static_cast< double >( std::rand() ) / static_cast< double >( RAND_MAX ); } inline void boost_( boost::math::gamma_distribution<>& d, double q ) { double value = boost::math::quantile( d, q ); } inline void att_bell( double alpha, double beta, double q ) { double q_Minus1 = 1 - q; double value = 0.0; double bound = 0.0; int which = 2; int status = 0; cdfgam( &which , &q , &q_Minus1 , &value , &alpha , &beta , &status , &bound ); } int main() { // boost { std::srand( 0 ); boost::timer timer; for( std::size_t y = 0; y < max_year; ++y ) { if(( y % 100000 ) == 0 ) std::cout << y << std::endl; double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std; double alpha = mean * mean / std / std; // shape parameter double beta = mean / alpha; // scale parameter boost::math::gamma_distribution<> d( alpha, beta ); boost_( d, right ); boost_( d, left ); } std::cout << ""Boost - Time elapsed: "" << timer.elapsed() << "" sec"" << std::endl; } // att bell { std::srand( 0 ); boost::timer timer; for( std::size_t y = 0; y < max_year; ++y ) { if(( y % 100000 ) == 0 ) std::cout << y << std::endl; double mean = get_rand() * ( max_mean - min_mean ) + min_mean; double std = get_rand() * ( max_std - min_std ) + min_std; double alpha = mean * mean / std / std; // shape parameter double beta = mean / alpha; // scale parameter att_bell( alpha, beta, right ); att_bell( alpha, beta, left ); } std::cout << ""ATT Bell - Time elapsed: "" << timer.elapsed() << "" sec"" << std::endl; } return 0; } " chhenning@… karsten 10946 Add dt to system arguments odeint To Be Determined Feature Requests 2015-01-20T17:25:03Z 2015-01-29T21:29:57Z "A popular algorithm for calculating the change in velocity of a charged particle in a magnetic field (1) requires the length of the time step while integrating (dx/dt := f(x,t,dt)) and cannot be used with odeint as far as I could tell so I suggest modifying the definition of system from sys( x , dxdt , t ) to sys( x , dxdt , t , dt ). Some enable_if magic should allow all existing code using the current API to work. (1) Equations 25 and 26 in (h)ttp://www.dtic.mil/dtic/tr/fulltext/u2/a023511.pdf" ilja.j.honkonen@… marshall 7494 boost::replace_all is very slow on debug build when Format size is big string_algo To Be Determined Bugs 2012-10-11T09:28:38Z 2016-07-11T21:34:40Z "Method boost::replace_all(SequenceT& Input, const Range1T& Search, const Range2T& Format) on debug build takes very long time when Format size is about 300k. On call stack I can see push_front for every char. When I use std::find and std::replace in loop it is cca 10 times faster. I have Boost library 1.45, Visual Studio 2010, Win7 x64 SP1, 6-core CPU." Jan Vonasek marshall 6160 support for (istream >> array < char >) array To Be Determined Feature Requests 2011-11-22T00:38:37Z 2011-11-28T17:17:25Z "1. `array < T >` is a replacement for `T []` 1. the standard library provides the syntax `(istream >> char [])` and `(ostream << char const [])` 1. Currently, `(istream >> array < char >)` does not mean anything 1. this functionality cannot be simulated even with `std:: copy_n < istreambuf_iterator >` without manual termination and much verbosity == My implementation == {{{ #!cpp #include /* for ::boost:: array */ #include #if +BOOST_VERSION <= 0313720 #include /* for ::std:: setw */ namespace boost { /* helper classes to prevent ambiguity in matching array < char > */ namespace detail_ { /* normally, other char for every character type is char */ template < class P_C > class other_char { public: typedef char type; }; /* but other_char is undefined for char */ template <> class other_char < char > {}; /* class same_stream fails for istream */ template < class P_S, class P_C = typename other_char < typename P_S:: char_type >:: type > class same_stream { public: typedef P_S stream; }; } /* template input */ template < class P_C, class P_T, ::std:: size_t P_N > static inline ::std:: basic_istream < P_C, P_T > &operator >> (::std:: basic_istream < P_C, P_T > &p_s, ::boost:: array < P_C, P_N > &p_a) { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); } /* character input, disabled for type char to avoid ambiguity */ template < class P_C, class P_T, ::std:: size_t P_N > static inline typename detail_:: same_stream < ::std:: basic_istream < P_C, P_T > >:: stream &operator >> (::std:: basic_istream < P_C, P_T > &p_s, ::boost:: array < char, P_N > &p_a) { return p_s >> ::std:: setw (p_a. static_size) >> p_a. data (); } /* template output */ template < class P_C, class P_T, ::std:: size_t P_N > static inline ::std:: basic_ostream < P_C, P_T > &operator << (::std:: basic_ostream < P_C, P_T > &p_s, ::boost:: array < P_C, P_N > const &p_a) { return p_s << p_a. begin (); } /* character output, disabled for type char */ template < class P_C, class P_T, ::std:: size_t P_N > static inline typename detail_:: same_stream < ::std:: basic_ostream < P_C, P_T > >:: stream &operator << (::std:: basic_ostream < P_C, P_T > &p_s, ::boost:: array < char, P_N > const &p_a) { return p_s << p_a. begin (); }} #endif /* BOOST_VERSION */ #include /* for EXIT_SUCCESS */ #include /* for BUFSIZ */ #include /* for ::std:: cin */ int main () { // char (&x) [+BOOST_VERSION] = 0; #ifdef ARRAY_IN_NATIVE /* native code */ char t [+BUFSIZ]; return ::std:: cin >> ::std:: setw (+BUFSIZ) >> t && ::std:: cout << t << '\n'? +EXIT_SUCCESS: +EXIT_FAILURE; #else /* ARRAY_IN_NATIVE */ /* equivalent Boost code */ ::boost:: array < char, +BUFSIZ > t; /* check that character input compiles for wchar_t */ (void) sizeof (std:: wcin >> t); return ::std:: cin >> t && ::std:: cout << t << '\n'? +EXIT_SUCCESS: +EXIT_FAILURE; #endif /* ARRAY_IN_NATIVE */ } }}} " giecrilj@… marshall 6683 find family of functions needs const Range1T& Input overloads algorithm To Be Determined Feature Requests 2012-03-13T14:16:05Z 2012-03-14T08:54:17Z It's cumbersome to have to create named temporaries when searching using these functions. I presume the reason for why Input isn't const is due to the fact that iterator_range<> that's returned can modify Input. In the spirit of std & the rest of boost I propose an overload which returns const_iterator_range<>, which would provide the same functionality as iterator_range<> save for being able to modify the source. sairony@… marshall 6793 Support construction from range array To Be Determined Feature Requests 2012-04-14T20:46:23Z 2012-12-17T17:31:46Z "Could you support construction from a range and from an iterator pair? I don't know what to do when the input doesn't match the array size. If it's smaller you could default construct the rest of the array. If it's larger, you could truncate, std::terminate() or throw. Or just consider it undefined behaviour." Olaf van der Spek marshall 7652 compile-time checked access array Boost 1.54.0 Feature Requests 2012-11-06T06:56:56Z 2013-02-12T18:11:23Z "Since code like boost::array test; test[2] = 1; test[-1] = 1; compiles correctly on some compilers (even without warnings). I suggest adding compile checked functions for static access to arrays like: template reference at() { BOOST_STATIC_ASSERT( (i < N) ); return elems[i]; } template const_reference at() const { BOOST_STATIC_ASSERT( (i < N) ); return elems[i]; } then code like: boost::array test; test.at<2> = 1; test.at<-1> = 1; would result in the expected errors." Tobias Loew marshall 9287 Additional string_ref constructors utility To Be Determined Feature Requests 2013-10-22T09:09:19Z 2015-05-12T00:57:48Z "From: - iterator_range - std::vector - pair of iterators" Domagoj Šarić marshall 9576 read_until for string_ref algorithm To Be Determined Feature Requests 2014-01-15T15:13:20Z 2014-01-24T09:04:41Z "{{{ string_ref read_until(string_ref& is, const char* sep); }}} Could we have a function like this that reads until a separator, returns the part before the separator and then eats the separator? It should read and return the entire input if no separator is found." Olaf van der Spek marshall 9577 trim_copy doesn't support string_ref algorithm To Be Determined Feature Requests 2014-01-15T19:07:55Z 2014-03-31T20:00:27Z "{{{ boost::string_ref z = "" AA BB ""; boost::string_ref b = boost::trim_copy(z); }}} does not compile" ml@… mkaravel 10983 box-box distance doesn't seem to work with spherical coordinate systems geometry Boost 1.59.0 Bugs 2015-01-29T23:29:45Z 2015-05-11T05:25:04Z "The ""geometry distance matrix"" indicates that all geometry-to-geometry distances have been implemented in 1.57. But the box-to-box distance doesn't seem to work with spherical geometries, at least with gcc 4.4.7. One of the errors seems to be a ""not yet implemented"" error, so perhaps it hasn't been done yet. It does have some tricky business that a cartesian box wouldn't have, but it's a straightforward exercise in trying different cases. I'm certainly delighted with boost::geometry's functionality as is, but it would be great if this worked. And many apologies if the mistake is mine. See example below for problem. ---- {{{ #include typedef boost::geometry::model::point cartesian_point; typedef boost::geometry::model::point > spherical_point; int main() { // Works... boost::geometry::model::box c_box1, c_box2; boost::geometry::distance(c_box1,c_box2); // Doesn't work! boost::geometry::model::box s_box1, s_box2; boost::geometry::distance(s_box1,s_box2); return 0; } }}} " mdrinto@… mumiee 1201 Regexify the syntax highlighter quickbook To Be Determined Feature Requests 2007-08-22T23:27:56Z 2007-08-26T09:37:26Z "What I'd really want is to Regex-ify the syntax highlighter and have them reconfigurable as user-supplied regex strings from configuration files. This would simplify our life a lot. There'll be only one syntax highlighter grammar and code that can accept various lexer files. Our job then is just to churn out various lexer files for different languages. " Joel de Guzman neilgroves 7630 Range adaptors do not play nicely with range-based for loops range To Be Determined Bugs 2012-11-02T18:37:22Z 2016-06-02T23:18:04Z "Consider the following C++11 code, adapted from the Range documentation: {{{ std::vector vec; for (int val : vec | boost::adaptors::reversed | boost::adaptors::uniqued) { // Do stuff with val } }}} The behavior of this natural-seeming code is actually undefined, due to a dangling reference: per the C++ standard, it is equivalent to {{{ { auto && __range = (vec | boost::adaptors::reversed | boost::adaptors::uniqued); for ( auto __begin = __range.begin(), __end = __range.end(); __begin != __end; ++__begin ) { int val = *__begin; // Do stuff with val } } }}} The problem is that the value returned by the subexpression `vec | boost::adaptors::reversed` is a temporary, so its lifetime ends at the end of the statement containing it, namely the declaration of `__range`. Thus, `__range` is left holding a dangling reference to the range it's adapting. The fix is for each range adaptor to use an rvalue-reference overload to detect whether the input range is a temporary, and if so, move it into the adaptor (i.e. with `std::move`) in order to extend its lifetime. " gromer@… neilgroves 10142 Range lib type_erased.cpp needs /bigobj option for mcvc and intel-win range To Be Determined Bugs 2014-06-23T11:37:00Z 2014-08-25T21:12:23Z "Build of range lib on debug mode fails with msvc and icl on type_erased.cpp file. /bigobj option should be added to Jamfile.v2 # ../../../bjam --toolset=intel address-model=364 . . . file ..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp ""adaptor_test\type_erased.cpp"" -Fo""..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj"" -TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /favor:blend /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 -DBOOST_TEST_NO_AUTO_LINK=1 ""-I..\..\.."" compile-c-c++ ..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj call ""C:\Program Files (x86)\microsoft visual studio 12.0\vc\vcvarsall.bat"" x86_amd64 >nul cl /Zm800 -nologo @""..\..\..\bin.v2\libs\range\test\type_erased.test\msvc-12.0\debug\address-model-64\link-static\threading-multi\adaptor_test\type_erased.obj.rsp"" type_erased.cpp C:\Users\. . .\boost_1_55_0\libs\range\test\adaptor_test\type_erased.cpp : fatal error C1128: number of sections exceeded object file format limit : compile with /bigobj On Intel Windows 13.1, 14,0, 15.0: # ../../../bjam --toolset=intel address-model=64 . . . type_erased.cpp ..\..\..\bin.v2\libs\range\test\type_erased.test\intel-win\debug\link-static\threading-multi\adaptor_test\type_erased.obj"": catastrophic error: too many segments in object file compilation aborted for adaptor_test/type_erased.cpp (code 4) " Elmira Semenova neilgroves 10332 »indexed« range adaptor's source-breaking change not mentioned in release notes range To Be Determined Bugs 2014-08-09T20:45:26Z 2014-09-01T11:54:45Z "The »indexed« range adaptor has changed in v1.56.0 in source-breaking ways. I get the change and that it was necessary for range-based for loops, but this means that you now have to `#if BOOST_VERSION < …` around it. See [[http://boost.codepad.org/VE1QSmSz|this example]] (distilled from actual code). Why the ticket? Because the change hasn't been mentioned at all in the [[http://www.boost.org/users/history/version_1_56_0.html|release notes]]." Moritz Bunkus neilgroves 10336 compilation error in iterator_range and unordered_map range To Be Determined Bugs 2014-08-10T08:07:32Z 2015-01-31T14:52:10Z "I get a compilation error with vc10, iterator_range and a (const) unordered_map (the beta candidate 2 was still ok I think): {{{#!cpp #include ""stdafx.h"" #include #include int _tmain(int /*argc*/, _TCHAR* /*argv*/[]) { typedef boost::unordered_map Container; typedef Container::const_iterator ContainerIterator; typedef boost::iterator_range ContainerIteratorRange; const Container cnt; ContainerIteratorRange rng(cnt.cbegin(), cnt.cend()); return 0; } }}} This gives C2248: 'boost::unordered::iterator_detail::c_iterator::iterator' cannot access private typedef declared in class etc. Eric: Niebler: Well, this is unfortunate. It's broken also on msvc-12 and clang trunk, but strangely not on gcc. I thought it might be due to this change in Boost.Range: github.com/boostorg/range/commit/264017e2a9bdbfcc24517ce05f8ef96df0a8c45b But reverting that doesn't have any effect. It works on Boost 1.55, so this is definitely a regression. Can you please file a bug? Neil, can you take a look? A possible fix: github.com/boostorg/range/pull/19 " gast128@… neilgroves 10360 Since 1.56, any_range use static cast of reference instead of implicit conversion range To Be Determined Bugs 2014-08-15T13:54:28Z 2014-12-19T12:47:57Z "Since 1.56, when dereferencing, any_range tries to use static cast of reference instead of implicit conversion like in 1.55. Here is an example that works with 1.55 but fails to compile with 1.56. {{{ #include #include #include struct A {}; int main() { std::vector > v; boost::any_range, boost::forward_traversal_tag, std::shared_ptr, std::ptrdiff_t> r(v); } }}} " vdavid@… neilgroves 10397 compilation error with mfc-iteratior-support: ambiguous symbol range To Be Determined Bugs 2014-08-25T08:19:11Z 2014-08-30T14:33:50Z "Hi, moving parts of range_const_iterator to the namespace range_detail in file boost/range/const_iterator.hpp leads to ambiguity in /range/detail/mfc.hpp line 747: (MSVC 11 on Windows Server 2008 R2/x64) 25>..\src\libs\boost\boost\boost/range/mfc.hpp(747): error C2872: 'range_const_iterator' : ambiguous symbol 25> could be '..\src\libs\boost\boost\boost/range/const_iterator.hpp(67) : boost::range_const_iterator' 25> or '..\src\libs\boost\boost\boost/range/const_iterator.hpp(40) : boost::range_detail::range_const_iterator' 25> ..\src\libs\boost\boost\boost/range/detail/microsoft.hpp(135) : see reference to class template instantiation 'boost::range_detail_microsoft::customization::meta' being compiled 25> with 25> [ 25> Tag=CEbsValueArray::mfc_range_base_type, 25> X=CTypedPtrArray 25> ] 25> ..\src\libs\boost\boost\boost/range/begin.hpp(111) : see reference to class template instantiation 'boost::range_detail_microsoft::const_iterator_of' being compiled 25> with 25> [ 25> T=CTypedPtrArray 25> ] ... The problem can be resolved by changing the name of boost::range_detail::range_const_iterator to boost::range_detail::range_const_iterator_helper I expect other begin/end adapters to run into the same problem. Tobias " Tobias Loew neilgroves 10430 joined_range generates invalid range with recent gcc versions with optimization enabled range To Be Determined Bugs 2014-08-30T19:40:42Z 2014-09-01T11:54:18Z "This came up in tracking down unit-test failures when trying to build a project with newer compiler versions with C++11 enabled. The unit-test in question was compiled with multiple compiler versions: * gcc 4.3.4 (without C++11 enabled): working at all optimization levels * gcc 4.7.2 (with C++11 enabled): works without optimizations, failed with -O1 or higher * gcc 4.8.4 (with C++11 enabled): works without optimizations, failed with -O1 or higher * clang 3.5.0 (recent build, with C++11 enabled): works at all optimization levels The failure was tracked down to a use of boost::range::joined_range (Boost 1.55.0), effectively declared as: {{{ boost::range::joined_range::iterator, boost::iterator_range> }}} In this form, the joined_range created from two valid ranges winds up ""somewhere else"" when the higher optimization level. I've attached a test case that demonstrates the problem. Compiled with: {{{ g++ -std=c++11 -o join_bug join_bug.cpp }}} works (printing out the expected ASCII values of the joined ranges). Compiled with: {{{ g++ -O1 -std=c++11 -o join_bug join_bug.cpp }}} fails (printing out zero's in my test, though the correct number of them). This test was run with the same compiler versions as above, on both Boost 1.54.0 and Boost 1.55.0, as well as gcc 4.8.2 and clang 3.4 (both for Ubuntu 14.04), with a slightly modified non-C++11 version for the gcc 4.3.4 compiler, all with the same successes/failures. The problem goes away in all tests if the joined_range is declared like so (changing from std::vector::iterator to std::vector::const_iterator): {{{ boost::range::joined_range::const_iterator, boost::iterator_range> }}} I realize this might be a gcc bug, rather than a Boost bug, but I haven't seen this reported elsewhere and would like to get the behaviour tracked since I'm only seeing problems in relation to joined_range... " Oliver Seiler neilgroves 10483 boost::is_sorted docs incorrectly describe predicate range Boost 1.58.0 Bugs 2014-09-09T13:13:34Z 2015-02-02T01:20:47Z "From the documentation For the non-predicate version the return value is true if and only if for each adjacent elements [x,y] the expression x < y is true and similarly for the predicate version. This isn't the case however. From the standard [alg.sorting] A sequence is sorted with respect to a comparator comp if for any iterator i pointing to the sequence and any non-negative integer n such that i + n is a valid iterator pointing to an element of the sequence, comp(*(i + n), *i) == false. So the docs should say the expression y < x is false I get the following with g++'s underlying is_sorted(): {{{ std::vector v{1, 1}; std::cout << boost::is_sorted(v) << std::endl; // prints 1 }}} Reference for is_sorted at cplusplus.com [sorry not allowed to post a link] backs this up." charlie@… neilgroves 10493 Since 1.56, any_range with non-reference references can cause UB range Boost 1.64.0 Bugs 2014-09-11T14:04:19Z 2018-03-08T08:44:24Z "This must be related to #10360. This is a regression since 1.55. When using any_range, mutable dereference() method returns mutable_reference_type_generator::type, which becomes T&. So dereference() returns a dangling reference to an on-the-fly computed value. See attached test case, which works with 1.55, and fails with -fsanitize=address on Clang 3.5 with 1.56. {{{ #include #include #include #include typedef boost::any_range< std::string, boost::forward_traversal_tag, std::string, std::ptrdiff_t > range_t; std::string f(std::string a) { return a + ""!""; } int main() { std::vector v = {""a"", ""b""}; range_t r = v | boost::adaptors::transformed(f); for (auto&& a : r) std::cout << a << std::endl; return 0; } }}} " nofitserov@… neilgroves 10515 Range: doc: incorrect return type range Boost 1.58.0 Bugs 2014-09-18T07:51:57Z 2015-02-02T01:22:17Z "This page: http://www.boost.org/doc/libs/1_56_0/libs/range/doc/html/range/reference/adaptors/reference/filtered.html reads: {{{ Range Return Type: boost::filtered_range }}} But the code shows that it has two template parameters. {{{ namespace boost { namespace range_detail { template< class P, class R > struct filtered_range : }}} Maybe other similar pages lack parameters, I don't know, but they all seem to have a single one documented." akim demaille neilgroves 10865 boost::iterators::transform_iterator is not default constructible on Clang range Boost 1.58.0 Bugs 2014-12-11T09:49:25Z 2015-02-02T01:12:09Z "The attached code compiles with GCC 4.9.2 and MSVC 2013, but fails with Clang 3.5.0. I've first reported it against clang, but they explained that it's actually incorrect in Boost, see clang bug #21787 (the bugtracker rejects links here). " Balázs Kádár neilgroves 10988 Range filtered adapter incorrectly requires a ForwardRange range To Be Determined Bugs 2015-02-01T18:26:23Z 2015-02-01T19:06:54Z The filtered Range adapter incorrectly requires a ForwardRange. A SinglePassRange should be sufficient, since it is for the Boost.Iterator filter_iterator. Neil Groves neilgroves 10989 strided breaks on impure traversal tags range Boost 1.58.0 Bugs 2015-02-02T17:31:03Z 2015-02-02T20:19:32Z "From http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed [...]/boost/1.57.0/include/boost/range/iterator_range_core.hpp:216:20: error: no matching function for call to ‘boost::range_detail::strided_iterator >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::detail::iterator_category_with_traversal >::strided_iterator(boost::range_detail::strided_iterator >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::random_access_traversal_tag>&)’ , m_End(End) Problem is that make_begin_strided_iterator et al coerce the returned iterator traversal category/tag to a pure traversal tag, which doesn't necessarily agree with the Category passed to iterator_range for the base type. Fix is to use iterators::pure_iterator_traversal." anonymous neilgroves 7006 Restricted pointers support. range To Be Determined Feature Requests 2012-06-21T10:11:48Z 2014-03-09T18:11:10Z Trying to form iterator_ranges with restricted pointers causes compiler errors. Domagoj Šarić neilgroves 7742 tie like functionality for ranges range To Be Determined Feature Requests 2012-11-27T11:56:41Z 2014-03-03T01:50:10Z "The Graph library uses std::pair to pass ranges and this allows a nice pattern to use old-fashioned for-loops: Graph g; boost::graph_traits::vertex_iterator b, e; for(boost::tie(b, e) = vertices(g); b != e; ++b) { } This works without any modifications with pair. The functionality would be great for all ranges as it provides users that don't want to use Boost.Range algorithms with a simple way to use their preferred style or algorithms from std. " philipp.moeller@… neilgroves 12158 boost::size() and friends should use an ADL barrier like boost::begin range To Be Determined Feature Requests 2016-04-26T21:35:42Z 2016-04-26T21:55:11Z "boost::begin() and boost::end() are nicely declared in an ADL barrier namespace to avoid conflicts with code like this: {{{ using std::begin; auto i = begin(c); }}} [http://isocpp.org/files/papers/n4280.pdf N4280] has been accepted into C++17, which adds std::size, std::empty, and std::data. But if users attempt to use those in the same way: {{{ using std::size; auto s = size(c); }}} They may get an error. For example, if c is a std::vector> or something, boost::size() will be found by ADL, and since it's no more specific than std::size, the call will be ambiguous." Tavian Barnes nesotto 3483 non-null requirement in ptr_vector::transfer ptr_container Feature Requests 2009-09-23T09:40:17Z 2011-03-31T20:52:16Z "[http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support] is it possible to remove non-null requirement for ''from'' argument in ptr_vector::transfer method?" Igor Pavlov niels_dekker 2836 Request boost::optional::optional_assign_to, optional_move_to, optional_swap optional Boost 1.39.0 Feature Requests 2009-03-07T11:25:11Z 2009-03-07T12:46:48Z "I request the three member functions template< class U > bool boost::optional::optional_assign_to(U& t) const; template< class U > bool boost::optional::optional_move_to(U& t); bool boost::optional::optional_swap(T& t); which, if !*this, return false, and otherwise return true and are equivalent to t=**this; t=**this; and *this may have any value after the move std::swap( t, **this ); " aschoedl@… noel_belcourt 6954 property map 'put' should support move semantics property_map Boost 1.56.0 Bugs 2012-05-30T19:12:42Z 2014-01-27T23:48:48Z The 'put' helper function in the boost property map library should support move semantics. At the moment it takes the value to be put by const reference, I think it would be more appropriate to perfect forward it. wz258@… pdimov 12033 Boostdep misses some dependent components Building Boost To Be Determined Feature Requests 2016-02-29T21:33:12Z 2016-03-03T17:46:12Z "In creating a modular boost build for a client I found that boostdep was missing a few smaller libraries when tracing the dependencies. The library msm depends on fusion, which depends on utility, but boostdep does not list ""utility"" as among the depdencies of msm. For a test case, try building libs/msm/doc/HTML/examples/SimpleTutorial.cpp using a version of Boost with only the submodules listed as dependencies of msm. It should complain about not finding boost/utility/result_of.hpp" edaskel@… ramey 1836 bug in serializing wide character strings serialization To Be Determined Bugs 2008-04-17T21:12:21Z 2010-11-29T20:32:54Z "We've discovered an issue Boost has writing and reading wide character strings (wchar_t* and std::wstrings) to non-wide character file streams (std::ifstream and std::ofstream). The issue stems from the fact that wide characters are written and read as a sequence of characters (in text_oarchive_impl.ipp and text_iarchive_impl.ipp, respectively). For text streams, an EOF character terminates the reading of a file on Windows. Some wide characters have EOF (value = 26 decimal) as one of the bytes so reading that byte causes early termination of the read. We have worked around the issue by deriving our own input and output archives from text_i|oarchive_impl and overriding load_override() and save_override for std::wstring and wchar_t*. Our implementation just sequences through the wide characters and writes them 1 by 1 as wchar_t to the archive. This isn't very elegant and is even less readable in the file than the current implementation but does resolve the problem. Although the test test_simple_class does test wstrings, it only uses characters 'a'-'z' which does not expose this problem. " Jeff Faust ramey 2326 "Library does not directly support serializing data of type ""foo**""" serialization Boost 1.37.0 Bugs 2008-09-15T03:40:34Z 2008-09-18T15:44:22Z "The following example fails to compile, trying to find a .serialize() member function in an int*. Clearly the user can program around this, but serializing pointers-to-pointers seems a natural capability that should be in the library. #include #include ""boost/archive/text_oarchive.hpp"" class foo { friend class boost::serialization::access; template void serialize(archive& ar, const unsigned int version) { ar & BOOST_SERIALIZATION_NVP(buff); ar & BOOST_SERIALIZATION_NVP(ptr); } public: foo() : ptr(&buff[3]) {} int* buff[10]; int** ptr; }; int main() { foo f; std::ofstream serial(""serial""); boost::archive::text_oarchive oa(serial); oa << BOOST_SERIALIZATION_NVP(f); return 0; } " anonymous ramey 5629 base64 encode/decode for std::istreambuf_iterator/std::ostreambuf_iterator serialization To Be Determined Bugs 2011-06-22T13:29:41Z 2014-02-19T21:27:41Z "MSVS 2008 The code: {{{ #include ""boost/archive/iterators/base64_from_binary.hpp"" #include ""boost/archive/iterators/binary_from_base64.hpp"" #include ""boost/archive/iterators/transform_width.hpp"" //typedefs typedef std::istreambuf_iterator my_istream_iterator; typedef std::ostreambuf_iterator my_ostream_iterator; typedef boost::archive::iterators::base64_from_binary< boost::archive::iterators::transform_width< my_istream_iterator, 6, 8> > bin_to_base64; typedef boost::archive::iterators::transform_width< boost::archive::iterators::binary_from_base64< my_istream_iterator >, 8, 6 > base64_to_bin; void test() { { //INPUT FILE!!! std::ifstream ifs(""test.zip"", std::ios_base::in|std::ios_base::binary); std::ofstream ofs(""test.arc"", std::ios_base::out|std::ios_base::binary); std::copy( bin_to_base64( my_istream_iterator(ifs >> std::noskipws) ), bin_to_base64( my_istream_iterator() ), my_ostream_iterator(ofs) ); } { std::ifstream ifs(""test.arc"", std::ios_base::in|std::ios_base::binary); std::ofstream ofs(""test.rez"", std::ios_base::out|std::ios_base::binary); std::copy( base64_to_bin( my_istream_iterator(ifs >> std::noskipws) ), base64_to_bin( my_istream_iterator() ), my_ostream_iterator(ofs) ); } } }}} Result: 1) If the INPUT FILE will be any of ZIP-file format. The result was: a) _DEBUG_ERROR(""istreambuf_iterator is not dereferencable""); //it can be disabled or ignored b) The encoded file ""test.rez"" will have one superfluous byte than INPUT FILE 2) If the INPUT FILE will any other file (binary or text) all will be OK. " nen777w@… ramey 5876 Serialization - tracking of non-versioned classes serialization To Be Determined Bugs 2011-09-08T09:42:18Z 2016-04-05T10:51:57Z "I quote a case from my workplace. The issue came up for std::vector, but I use a simple struct X to reproduce the problem. See the attached file for detailed instructions. Opened by Yakov Galka 9/8/2011 (Today) 8:31 AM Edit The following code: {{{ struct X { ... }; X x2; BoostLoad(""SerializationBug.dat"", x2); #if FLAG volatile int x = 0; if(x) { X *x3; BoostLoad(""this code is never executed"", x3); } #endif }}} Produces different results depending on whether FLAG == 0 or 1, although it's clear that it must not change it's behavior. After some research it happens that the handling of tracking level is broken in boost since at least boost 1.46.1. Assigned to Yakov Galka by Yakov Galka 9/8/2011 (Today) 8:31 AM Notified ######. Edited by Yakov Galka 9/8/2011 (Today) 8:53 AM [Revised 11:44 AM] Edit It happens for objects with implementation level of object_serializable. That is: {{{ BOOST_CLASS_IMPLEMENTATION(X, boost::serialization::object_serializable) }}} For greater implementation level, the tracking level is read from the archive. However it still must affect the saving of objects to any archives (binary, xml, text). If it's not clear enough, the above code reads/writes the the file correctly when FLAG == 0, but tries to load x2 as-if it's tracked when FLAG == 1. Edited by Yakov Galka 9/8/2011 (Today) 10:38 AM Edit I've successfully reproduced this same bug in boost 1.33.1, although there it's silent (no crash, just wrong data is read). Boost serialization is broken really hard on the low-level: basic_iserializer::tracking() decides whether the class should be tracked or not based on m_bpis value. However it can't decide this based on the information it has, since it's shared among objects serialized trough a pointer and not through a pointer. Possible Fix: make basic_iserializer::tracking return the tracking level instead of a boolean value and let the caller decide what this tracking level means. It's a lot of work, and it may break computability with archives serialized incorrectly in 1.33.1, which happens to be possible. We are screwed anyway. Edited by Yakov Galka 9/8/2011 (Today) 11:44 AM Revised Yakov Galka's 8:53 AM entry from 9/8/2011" ybungalobill@… ramey 6515 Serilaization of std::vector is broken for optimizing archives serialization To Be Determined Bugs 2012-02-02T18:40:38Z 2012-07-15T20:35:16Z "Serializing a vector causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp): {{{ template inline void save( Archive & ar, const std::vector &t, const unsigned int /* file_version */, mpl::true_ ){ const collection_size_type count(t.size()); ar << BOOST_SERIALIZATION_NVP(count); if (!t.empty()) ar << make_array(detail::get_data(t),t.size()); } }}} While detail::get_data(t) is not specialized for std::vector (but it should be), and t.size() returns the number of bits stored in the vector, which is probably not what's expected either. I'm encountering this problem with MSVC10, 64bit, Windows7." Hartmut Kaiser ramey 12741 Linker error in cross compiling with x86_64-w64-mingw32-g++ serialization To Be Determined Bugs 2017-01-10T11:31:22Z 2017-09-08T14:53:37Z "Using {{{ using gcc : i686 : i686-w64-mingw32-g++ ; using gcc : x86_64 : x86_64-w64-mingw32-g++ ; }}} in tools/build/src/user-config.jam with x86_64-w64-mingw32-g++ (GCC) 5.3.1 20160211 and calling {{{ ./b2 toolset=gcc-x86_64 address-model=64 link=shared --stagedir=x64 target-os=windows threading=multi threadapi=win32 variant=release --with-date_time --with-filesystem --with-graph --with-math --with-program_options --with-serialization --with-system --with-thread --with-timer }}} gives linker errors {{{ gcc.link.dll bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/libboost_wserialization.dll.a bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/basic_text_wiprimitive.o:basic_text_wiprimitive.cpp:(.rdata$.refptr._ZTVN5boost7archive12codecvt_nullIwEE[.refptr._ZTVN5boost7archive12codecvt_nullIwEE]+0x0): undefined reference to `vtable for boost::archive::codecvt_null' bin.v2/libs/serialization/build/gcc-mingw-x86_64/release/target-os-windows/threadapi-win32/threading-multi/xml_wiarchive.o:xml_wiarchive.cpp:(.rdata$.refptr._ZTVN5boost7archive6detail18utf8_codecvt_facetE[.refptr._ZTVN5boost7archive6detail18utf8_codecvt_facetE]+0x0): undefined reference to `vtable for boost::archive::detail::utf8_codecvt_facet' }}} The 32bit version i686-w64-mingw32-g++ with toolset=gcc-i686 address-model=32 works." zimmermann@… ramey 12837 Binary serialization: crash that may allow jump to attacker-controlled address serialization To Be Determined Bugs 2017-02-14T18:11:12Z 2017-05-04T16:25:16Z "Using afl-fuzz on some simple programs that use boost binary and xml serialization, I have found a number of crashes and assertion failures. To test the waters, I am beginning by filing a single bug which may allow a jump to an attacker-controlled address (i.e., the most exploitable-looking crash that has turned up so far). On my test system, it crashes on the instruction shown: {{{ => 0x000000000044849c <+524>: mov (%r12),%rax 0x00000000004484a0 <+528>: mov 0x20(%rbp),%r15d 0x00000000004484a4 <+532>: mov %r12,%rdi 0x00000000004484a7 <+535>: callq *0x10(%rax) }}} Notice that the value loaded at instruction <+524> is used to determine the address to call at instruction <+535>. The value of %r12 interpreted as bytes is ""\0\0hive\0\0"", which makes me strongly suspect that it is data from the input file (part of the 'serialization::archive' signature, masked off). Generally, the whole text of the input file would be considered under the control of the adversary. I ran my tests on Debian Jessie amd64 with gcc version 4.9.2 (Debian 4.9.2-10). The following revisions of modularized boost were used (the tip of each master branch at the time of writing, as described by 'git describe --tags --always): {{{ config: boost-1.62.0-57-g1abc59c core: boost-1.61.0-59-gd753d9a move: boost-1.63.0 serialization: boost-1.61.0-57-g62bf8fc }}} The commandline to compile the (non-fuzzing) version of the input test program is: {{{ g++-4.9 -std=c++11 -Os -I serialization/include -I core/include -I move/include -I config/include -o pvec_in pvec_in.cc serialization/src/extended_type_info.cpp serialization/src/extended_type_info_typeid.cpp serialization/src/archive_exception.cpp serialization/src/basic_archive.cpp serialization/src/basic_serializer_map.cpp serialization/src/void_cast.cpp serialization/src/singleton.cpp serialization/src/basic_iarchive.cpp serialization/src/binary_iarchive.cpp serialization/src/basic_iserializer.cpp serialization/src/basic_pointer_iserializer.cpp }}} The breaking input file is (base-64 encoded): {{{ FgAAAAAAAABzZXJpYWxpemF0aW9uOjphcmNoaXZlDwAECAQIAQAAAAAAAAAAAwAAAAAAAAABAAAA AAEAAAD0/wEAAAAAAAAAAAEAAAACAAEAAAACAAAAAgAAAAAA }}} The source for the test harness program (pvec_in.cc) is {{{ #include #include #include #include #include #include #include struct boxed_int { boxed_int() : i(0) {} boxed_int(int i) : i(i) {} int i; template void serialize(Archive &ar, unsigned version) { ar & BOOST_SERIALIZATION_NVP(i); } }; typedef boost::shared_ptr pi; void go(std::istream &is) { std::vector vv; try { boost::archive::binary_iarchive ia(is); ia & vv; } catch(std::exception &e) {} } int main(int argc, char **argv) { if(argc > 1) { std::ifstream is(argv[1]); go(is); } else { go(std::cin); } return 0; } }}} The test harness program either takes the input file on stdin or the name of the input file as the first positional argument. I can share details about the fuzzing setup if you like. Thank you for taking the time to consider this issue. --Jeff" jepler@… ramey 12913 Undefined behaviour in serialization library serialization To Be Determined Bugs 2017-03-19T18:28:47Z 2017-05-04T16:12:02Z "Hi Robert, while testing multiprecision with clang's sanitizers I found some undefined behaviour in the serialization lib. The issue can be seen by running serialization's own tests with undefined-behaviour sanitizer turned on - in fact nearly all the tests fail, but most of the failures look like issues with the tests rather than the library. However building test_binary_xml_archive with clang++ -fsanitize=address -fsanitize=undefined -fno-sanitize-recover=undefined results in: {{{ ../../../boost/archive/detail/interface_oarchive.hpp:47:16: runtime error: downcast of address 0x7ffd0a934990 which does not point to an object of type 'boost::archive::xml_oarchive' 0x7ffd0a934990: note: object is of type 'boost::archive::xml_oarchive_impl' 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' SUMMARY: AddressSanitizer: undefined-behavior ../../../boost/archive/detail/interface_oarchive.hpp:47:16 in }}} Which looks like a genuine issue to me. " John Maddock renficiaud 13007 When BOOST_BIND_NO_PLACEHOLDERS is defined, framework.ipp seems to be missing an #include test Boost 1.65.0 Bugs 2017-05-03T18:12:22Z 2017-07-07T21:22:41Z "Like the summary says, I think boost/test/impl/framework.ipp should simply have one additional #include so it works when BOOST_BIND_NO_PLACEHOLDERS is defined. " bspencer@… renficiaud 12240 Documentation for data-driven testing should explictly mention std::tuple test To Be Determined Feature Requests 2016-05-31T14:09:03Z 2016-09-29T14:14:53Z "`BOOST_DATA_TEST_CASE()` handles ranges of `std::tuple`s differently to ranges of other types, in that it expects to be able to expand the parts of the tuples out to multiple variables. Whether or not this is intended or just a side-effect of the implementation, I think it's a sensible behaviour. Indeed, it's quite useful to be able to supply `BOOST_DATA_TEST_CASE()` with pre-zipped data rather than always having to use `^`. However at the moment, this special handling of `std::tuple` is not documented. Hence I suggest that this be included in the documentation (possibly near the ""Zips"" section) or otherwise that the implementation is changed so that users' ranges of `std::tuple`s are treated like ranges of other types (ie each tuple is expanded to one variable). Many thanks for your work on this library." Tony Lewis renficiaud 12902 boost test labels test Boost 1.68.0 Support Requests 2017-03-13T18:20:16Z 2018-06-21T05:13:35Z "there is a tutorial about new boost test feature - the labels. but it is not clear how to run all tests in testsuite except those that are with a specific label. could you help, please?" dimitry rsd 8498 cray.jam doesn't build .so files Building Boost To Be Determined Bugs 2013-04-26T04:16:30Z 2013-10-14T13:49:35Z The current cray.jam file doesn't build dynamic libraries because of the lack of the -fPIC flet ag. On my my system I made the following changes (in attached patch) and was able to get ec.verything to build. I'm not a boostjam expert, I just modelled my changes on the pgi.jam and gcc.jam files. So some of these changes might not be appropriate. alan@… steven_watanabe 9704 b2: Compiler flavour has no flexibility for cross-compiling projects. build To Be Determined Bugs 2014-02-24T20:39:19Z 2014-04-04T22:13:25Z "Hi, I've been trying hard, but it is annoying, didn't find it elsewhere and it could really be improved. I am building my project (i.e. all of my project tree) on 2 platforms: * Windows, * Linux, for 3 different platforms: * Windows * Linux IA32 * Linux ARM HF Now, whilst b2 subsystem is quite flexible in specifying different types of compilers, it is not so much when using the same type of compiler, but using different versions of it. I have managed to define it somehow, i.e. in my project_config.jam (@ home dir): {{{ if [ os.name ] = NT { using gcc : : : -std=c++11 ""-include cmath"" -Wdeprecated-declarations ; using gcc : armhf : arm-linux-gnueabihf-g++.exe : -std=c++11 ""-include cmath"" -Wdeprecated-declarations ; } if [ os.name ] = LINUX { using gcc : : : -std=c++11 ""-include cmath"" ; using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ : -std=c++11 ""-include cmath"" -Wdeprecated-declarations ; } }}} But now, in every sub-project, where I'm moving files to a 'release' location, (* and whenever I need to specify copmiler-flavor specific configuration) I need to perform something like: {{{ install copy_binaries_to_release : target_names.. : linux:4.7:../../release/ windows:gcc-4.7.2-mingw:../../release/ armhf:../../release_armhf/ gcc-mingw-armhf:../../release/ ; }}} Is there a better way of doing it? If not, then the problem (and I guess a bug) is that b2 behaves differently on different platforms, somewhat lacks of mechanism to support what I need to do (and it's not really very uncommon). Problems: 1. Different toolset names when building on different OSes (and yes, I did try to specify a default flavor, but see Problem 2). || || command || toolset || flavor || || gcc XA32(linux) || b2 || gcc || 4.7 || || gcc XA32(win) || b2 || gcc-4.7.2-mingw || ? || || '''gcc armhf(linux)''' || '''b2 --toolset=gcc-armhf''' || '''gcc''' || '''armhf''' || || gcc armhf(win) || b2 --toolset=gcc-armhf target-os=linux || gcc-mingw-armhf || ? || Only gcc-armhf seems to achieve requested results. BUt the main issue it, that it is all different on different platforms, and both: armhf should produce compatible binaries. BTW: is there really a need to distinguish between e.g. Cygwin and MinGW flavours if they produce the same target with the same version of compiler? If one builds from Cygwin and MinGW for the same platform: resulting executables should be compatible for the same target, so only in 'bin' build directory they can really be different (if needed), but it is unlikely that one builds both of them (target:gcc version) at the same time (like it is unlikely that I build under windows and linux at the same time). 2. It is not possible to specify a flavor for GCC (by explicitly giving it a name and compiler location) - because b2 is performing a version check. This check either fails, or if it does not (and default version is used) - automatic build-platform-specific flavor value is created behind the control) - probably because b2 is trying to be too clever at this. Couldn't it leave it alone, and use flavor that was explicitly specified? I really wish that I could specify above: {{{ using gcc : 4.7 : ... ; using gcc : armhf : ... ; }}} and wouldn't have to create links or worry about the build system changing/ coming up with a flavor by concatenating target name (e.g. on {{{ b2 --toolset=gcc-armhf }}} with g++ (and having to hack/create symlinks to match this etc.) - It should just accept what I specify, and use it 'as-is' (and if someone does something stupid - let them fail and fix it). There could also be a support for something like: {{{ import toolset ; if [ toolset.name ] == gcc { if [ toolset.flavor ] == flav_1 { } } # and my verbosive Jamfiles could be re-written to something like: local gcc_flavor = [ toolset.flavor ] ; install copy_binaries_to_release : target_names.. : gcc,4.7:../../release gcc,armhf:../../release_$(gcc_flavor) # or even to: gcc:../../release_$(gcc_flavor) ; }}} With a bit of guidance / advice from someone, who knows the build system well - I'm happy to help with implementing the above. Thanks, LUkasz. (BTW: what is the best component for build system / tools?) " lukasz.forynski@… takahashi 6026 phoenix block statement tries to copy objects instead of references phoenix To Be Determined Bugs 2011-10-14T16:17:15Z 2016-05-09T15:02:25Z "Let's use a simplest class, that can't be copied: {{{ class A { A() {} A(const A&); public: static A* construct() { return new A(); } const A& operator<<(const char *p) const { return *this; } }; A *pa = A::construct(); A &a = *pa; }}} The code which use this object one time normally works: {{{ (boost::phoenix::ref(a) << boost::phoenix::placeholders::_1)(""aaa""); }}} But when I try to use this object two times, I get an error: {{{ ( boost::phoenix::ref(a) << boost::phoenix::placeholders::_1 ,boost::phoenix::ref(a) << boost::phoenix::placeholders::_1 )(""aaa""); }}} Result: 'A::A' : cannot access private member declared in class 'A' Expecting: pass compilation and invoke ""A::operator<<"" two times. Note: preprocessing directive ""BOOST_SPIRIT_USE_PHOENIX_V3"" was defined." armagvvg@… takahashi 6911 [Phoenix V3] Add tr1_result_of specialization phoenix Boost 1.67.0 Bugs 2012-05-17T15:01:15Z 2018-01-19T19:51:45Z "To make `result_of` and `tr1_result_of` equivalent, we have to add specialization of `tr1_result_of`. (Boost.Phoenix V3 already has specialization of `result_of`.) Also, it would be nice to avoid specialization of `result_of`, when we use decltype-based `result_of`. (As for `tr1_result_of`, it should be specialized even when decltype-based `result_of` is used.) So, instead of {{{ template <...> struct result_of { typedef XXXX type; }; }}} we should write {{{ #if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE) template <...> struct result_of { typedef XXXX type; }; #endif template <...> struct tr1_result_of { typedef XXXX type; }; }}} A quick grep said the following files specialize `result_of`. * phoenix/core/actor.hpp * phoenix/function/function.hpp " Michel Morin theller 5558 Phoenix bind doesn't support bind construct phoenix To Be Determined Bugs 2011-05-23T15:37:50Z 2016-05-09T14:07:41Z "boost::bind uses bind in situations where it cannot determine the return type. This is useful for situations where you are binding to a method with a variable argument list such as printf. I'm not so much concerned with the bind construct as I'm unsure how to bind to functions such as printf. Is there a syntax for this when utilizing Phoenix bind that I have missed? Using boost::bind -- boost::bind( &printf, ""%d "", _1 )(42); Using phoenix::bind -- phx::bind( &printf, ""%d "", arg1 )(42); results in compilation error. " Michael Caisse troy 3450 [fix in git] Bug into boost::python::stl_input_iterator python USE GITHUB Boost 1.41.0 Bugs 2009-09-15T07:53:33Z 2009-09-21T07:59:44Z "I noticed that if you try to traverse more than once the range (begin,end) obtained with the `stl_input_iterator`, you don't get the expected results.[[BR]] [[BR]] Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).[[BR]] [[BR]] The problem is given by the call to the `std::distance` function.[[BR]] If you build with `-DWORK_AROUND` the problem disappears, but I need to call `std::distance`, because it is the original class that calls it (and I prefer not to modify it simply for building a python extension)." micdestefano@… troy 3673 boost python and weak_ptr from a shared_ptr argument python USE GITHUB Boost 1.43.0 Feature Requests 2009-11-26T07:22:57Z 2013-06-11T18:44:38Z "if you save a weak_ptr of a shared_ptr passed to you by python, it expires almost immediately (see use of aliasing constructor in shared_ptr_from_python.hpp). See also mail from Jahn Fuchs on c++-sig list subject: boost python and weak_ptr from a shared_ptr argument" troy d. straszheim troyer 2838 MPI Python bindings not installed correctly mpi Boost 1.46.0 Bugs 2009-03-09T09:22:55Z 2012-11-03T23:51:39Z "I've successfully built and installed boost.MPI and the Python bindings in my home dir. Unfortunately, the Python module ""mpi.so"" is installed directly in the lib/-path as all the other Boost libs. When setting the PYTHONPATH to point to this location, the boost.mpi python bindings are accessible only via ""import mpi"" from within Python, and not via ""import boost.mpi"", as described in the docs at http://www.boost.org/doc/libs/1_38_0/doc/html/mpi/python.html I think that the Python modules should go to a sudirectory ""boost"" in the lib path, or it should be fixed in the documentation. Otherwise, the boost.mpi Python bindings are gorgeous!" lenzo@… troyer 4657 Boost.MPI Compile failure with Python 3 mpi To Be Determined Bugs 2010-09-18T18:04:50Z 2013-12-03T09:18:26Z "Boost 1.44 configured to use Python 3.1 fails on two Boost.MPI files. The two fatal error messages are reproduced below, edited (see http://lists.boost.org/Archives/boost/2010/09/170659.php for the full error output). This failure was discussed in Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595786) and Andreas Kloeckner provided a patch. See attached. -Steve ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -D_REENTRANT -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I""."" -I""/usr/include/python3.1"" -I""/usr/lib/openmpi/include"" -I""/usr/lib/openmpi/include/openmpi"" -c -o ""bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/datatypes.o"" ""libs/mpi/src/python/datatypes.cpp"" libs/mpi/src/python/datatypes.cpp: In function ‘void boost::mpi::python::export_datatypes()’: libs/mpi/src/python/datatypes.cpp:20: error: ‘PyInt_Type’ was not declared in this scope In file included from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/mpi/python/serialize.hpp:25, from libs/mpi/src/python/datatypes.cpp:13: ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/datatypes.o... and ""g++"" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -g -D_REENTRANT -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_MPI_DYN_LINK=1 -DBOOST_MPI_PYTHON_DYN_LINK=1 -DBOOST_PYTHON_DYN_LINK=1 -DNDEBUG -I""."" -I""/usr/include/python3.1"" -I""/usr/lib/openmpi/include"" -I""/usr/lib/openmpi/include/openmpi"" -c -o ""bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/py_environment.o"" ""libs/mpi/src/python/py_environment.cpp"" libs/mpi/src/python/py_environment.cpp: In function ‘bool boost::mpi::python::mpi_init(boost::python::list, bool)’: libs/mpi/src/python/py_environment.cpp:53: error: cannot convert ‘char**’ to ‘wchar_t**’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t**)’ ...failed gcc.compile.c++ bin.v2/libs/mpi/build/gcc-4.4.5/release/debug-symbols-on/python-3.1/threading-multi/python/py_environment.o... " smr@… turkanis 2557 iostreams filtering_stream w/ gzip infinite loop when writing to a full drive iostreams Boost 1.38.0 Bugs 2008-12-01T19:27:03Z 2017-07-12T12:45:47Z "When a filtering_stream with a gzip_compressor is used to write to a full hard drive (i.e. insufficient free space), boost enters an infinite loop in /boost/iostreams/detail/adapter/non_blocking_adapter.hpp:41 because the write function keeps returning zero. This loop happens during the destruction of the stream. I can't seem to find a client-side workaround. Attached is a test case, point it to a volume with zero space and give some large number of bytes. If there's insufficient space, execution hangs. Tested on mingw/winxp/gcc4.2 but seems to fail on linux/gcc as well." Tomasz Śniatowski viboes 7319 Take care of c++std-lib-32966 issue thread To Be Determined Bugs 2012-09-02T08:32:23Z 2012-09-02T08:41:34Z "Take care of the issue raised by Howard Hinnant in [c++std-lib-32966] Public service announcement concerning ~condition_variable_any() ""Both condition_variable and condition_variable_any are based on the POSIX pthread_cond_t. One of the very subtle behaviors of pthread_cond_t is that it is ok for a pthread_cond_t to be destroyed after all waiting threads have been signaled (assuming no new threads initiate a wait). There's even an example demonstrating this at http://www.unix.org/online.html under the specification for pthread_cond_destroy. This subtlety is reflected in the Requires clause for the destructor of both condition_variable and condition_variable_any: > Requires: There shall be no thread blocked on *this. [Note: That is, all threads shall have been notified; they may subsequently block on the lock specified in the wait. This relaxes the usual rules, which would have required all wait calls to happen before destruction. Only the notification to unblock the wait must happen before destruction. The user must take care to ensure that no threads wait on *this once the destructor has been started, especially when the waiting threads are calling the wait functions in a loop or using the overloads of wait, wait_for, or wait_until that take a predicate. — end note ] To be *perfectly* clear, the following is ok: {{{ Thread A Thread B ... lk.lock() ... cv.wait(lk) lk.lock() ... cv.notify_one() ... cv.~condition_variable_any() ... lk.unlock() ... ... finally exits cv.wait // ok, not a data race }}} "" " viboes viboes 7912 boost:thread documentation for 1.50 does not mention BOOST_THREAD_WAIT_BUG thread To Be Determined Bugs 2013-01-21T11:25:12Z 2013-06-09T20:12:37Z "As I understood from the trac ticket [https://svn.boost.org/trac/boost/ticket/7089] and sources for boost 1.50, boost::thread 1.50 implicitly adds 100 ms to the sleep time of boost::this_thread::sleep and boost::thread_sleep on linux. If the fix for 7089 cannot be backported into 1.50, the warning about broken functionality must be present in the documentation for 1.50." Viatcheslav.Sysoltsev@… viboes 8600 wait_for_any hangs, if called with multiple copies of shared_future referencing same task thread To Be Determined Bugs 2013-05-21T11:50:16Z 2013-06-04T06:13:38Z "The following small test program shows the problem: {{{ #include #include int calculate_the_answer_to_life_the_universe_and_everything() { return 42; } int main(int argc, char* argv[]) { boost::packaged_task pt(calculate_the_answer_to_life_the_universe_and_everything); boost::shared_future fi1 = boost::shared_future(pt.get_future()); boost::shared_future fi2 = fi1; boost::thread task(boost::move(pt)); // launch task on a thread boost::wait_for_any(fi1, fi2); std::cout << ""Wait for any returned\n""; return (0); } }}} This program hangs infinitely in the call to boost::wait_for_any. From the docs I would expect this to work, because it's allowed to copy shared_futures. If this is not allowed, a possibility would be needed, to find out, if two shared_futures point to the same task or not. Currently wait_for_any is unusable, if there are chances, that multiple shared_futures point to the same result." Martin Apel viboes 11091 notify_all_at_thread_exit - ThreadSanitizer: data race thread To Be Determined Bugs 2015-03-09T23:43:03Z 2015-03-09T23:43:18Z " {{{ Test output: BenPope x86_64 Ubuntu - thread - notify_all_at_thread_exit_p / clang-linux-3.6~tsan~c14_libc++ Rev 9b68e2eec037cbcb6f96d7d54079e7e1a6a274ab / Mon, 09 Mar 2015 11:14:53 +0000 Compile [2015-03-09 15:31:08 UTC]: succeed ""clang++-3.6"" -c -x c++ -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -std=c++1y -stdlib=libc++ -fsanitize=thread -O0 -fno-inline -Wall -pthread -fPIC -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I"".."" -o ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o"" ""../libs/thread/test/sync/conditions/notify_all_at_thread_exit_pass.cpp"" Link [2015-03-09 15:31:08 UTC]: succeed ""clang++-3.6"" -Wl,-R -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-R -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-R -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-rpath-link -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-rpath-link -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -Wl,-rpath-link -Wl,""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi"" -o ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p"" -Wl,--start-group ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_thread.so.1.58.0"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_chrono.so.1.58.0"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_system.so.1.58.0"" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -fsanitize=thread -lc++ -lc++abi -pthread RmTemps /home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p rm -f ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o"" ""/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o"" Run [2015-03-09 15:31:08 UTC]: fail ================== WARNING: ThreadSanitizer: data race (pid=14082) Write of size 8 at 0x7fd7f9795c48 by thread T1: #0 boost::(anonymous namespace)::thread_proxy(void*) (libboost_thread.so.1.58.0+0x00000002567a) Previous write of size 8 at 0x7fd7f9795c48 by main thread: #0 (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() (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main (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::shared_ptr(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x0000000318e5) #1 boost::(anonymous namespace)::thread_proxy(void*) (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7d4c0000de58 by main thread (mutexes: write M24): #0 boost::shared_ptr::swap(boost::shared_ptr&) (libboost_thread.so.1.58.0+0x000000031796) #1 boost::shared_ptr::operator=(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x00000003142d) #2 boost::thread::start_thread_noexcept() (libboost_thread.so.1.58.0+0x000000025579) #3 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #4 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #5 main (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* boost::detail::heap_new, void (*)()>(void (*&&)()) (notify_all_at_thread_exit_p+0x0000004c6acb) #2 boost::thread::make_thread_info(void (*)()) (notify_all_at_thread_exit_p+0x0000004c3a87) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f82) #4 main (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() (notify_all_at_thread_exit_p+0x0000004c27d7) #2 __cxx_global_var_init10 (notify_all_at_thread_exit_p+0x0000004439cc) #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp (notify_all_at_thread_exit_p+0x000000443a43) #4 __libc_csu_init (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() (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr::shared_ptr(boost::shared_ptr const&) ================== ================== WARNING: ThreadSanitizer: data race (pid=14082) Write of size 8 at 0x7fd7f9795c38 by thread T1: #0 boost::shared_ptr::shared_ptr(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x0000000318f9) #1 boost::(anonymous namespace)::thread_proxy(void*) (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7fd7f9795c38 by main thread: #0 (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() (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr::shared_ptr(boost::shared_ptr const&) ================== ================== WARNING: ThreadSanitizer: data race (pid=14082) Read of size 8 at 0x7d4c0000de60 by thread T1: #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) (notify_all_at_thread_exit_p+0x0000004c7696) #1 boost::shared_ptr::shared_ptr(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x000000031929) #2 boost::(anonymous namespace)::thread_proxy(void*) (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&) (notify_all_at_thread_exit_p+0x0000004c71cb) #1 boost::shared_ptr::swap(boost::shared_ptr&) (libboost_thread.so.1.58.0+0x0000000317d6) #2 boost::shared_ptr::operator=(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x00000003142d) #3 boost::thread::start_thread_noexcept() (libboost_thread.so.1.58.0+0x000000025579) #4 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #5 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #6 main (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* boost::detail::heap_new, void (*)()>(void (*&&)()) (notify_all_at_thread_exit_p+0x0000004c6acb) #2 boost::thread::make_thread_info(void (*)()) (notify_all_at_thread_exit_p+0x0000004c3a87) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f82) #4 main (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() (notify_all_at_thread_exit_p+0x0000004c27d7) #2 __cxx_global_var_init10 (notify_all_at_thread_exit_p+0x0000004439cc) #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp (notify_all_at_thread_exit_p+0x000000443a43) #4 __libc_csu_init (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() (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) ================== ================== WARNING: ThreadSanitizer: data race (pid=14082) Write of size 8 at 0x7fd7f9795c40 by thread T1: #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) (notify_all_at_thread_exit_p+0x0000004c76aa) #1 boost::shared_ptr::shared_ptr(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x000000031929) #2 boost::(anonymous namespace)::thread_proxy(void*) (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7fd7f9795c40 by main thread: #0 (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() (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) ================== ================== WARNING: ThreadSanitizer: data race (pid=14082) Atomic write of size 4 at 0x7d080000ef88 by thread T1: #0 __tsan_atomic32_fetch_add /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:613:3 (notify_all_at_thread_exit_p+0x0000004a5256) #1 boost::detail::atomic_increment(int _Atomic*) (notify_all_at_thread_exit_p+0x0000004c77cc) #2 boost::detail::sp_counted_base::add_ref_copy() (notify_all_at_thread_exit_p+0x0000004c7749) #3 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) (notify_all_at_thread_exit_p+0x0000004c76e6) #4 boost::shared_ptr::shared_ptr(boost::shared_ptr const&) (libboost_thread.so.1.58.0+0x000000031929) #5 boost::(anonymous namespace)::thread_proxy(void*) (libboost_thread.so.1.58.0+0x0000000256a3) Previous write of size 8 at 0x7d080000ef88 by main thread (mutexes: write M24): #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd) #1 boost::detail::shared_count::shared_count >(boost::detail::thread_data*) (notify_all_at_thread_exit_p+0x0000004c6f67) #2 void boost::detail::sp_pointer_construct >(boost::shared_ptr*, boost::detail::thread_data*, boost::detail::shared_count&) (notify_all_at_thread_exit_p+0x0000004c6dd0) #3 boost::shared_ptr::shared_ptr >(boost::detail::thread_data*) (notify_all_at_thread_exit_p+0x0000004c6c7b) #4 boost::thread::make_thread_info(void (*)()) (notify_all_at_thread_exit_p+0x0000004c3a93) #5 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f82) #6 main (notify_all_at_thread_exit_p+0x0000004c0903) Location is heap block of size 24 at 0x7d080000ef80 allocated by main thread: #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd) #1 boost::detail::shared_count::shared_count >(boost::detail::thread_data*) (notify_all_at_thread_exit_p+0x0000004c6f67) #2 void boost::detail::sp_pointer_construct >(boost::shared_ptr*, boost::detail::thread_data*, boost::detail::shared_count&) (notify_all_at_thread_exit_p+0x0000004c6dd0) #3 boost::shared_ptr::shared_ptr >(boost::detail::thread_data*) (notify_all_at_thread_exit_p+0x0000004c6c7b) #4 boost::thread::make_thread_info(void (*)()) (notify_all_at_thread_exit_p+0x0000004c3a93) #5 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f82) #6 main (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() (notify_all_at_thread_exit_p+0x0000004c27d7) #2 __cxx_global_var_init10 (notify_all_at_thread_exit_p+0x0000004439cc) #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp (notify_all_at_thread_exit_p+0x000000443a43) #4 __libc_csu_init (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() (libboost_thread.so.1.58.0+0x0000000255b0) #2 boost::thread::start_thread() (notify_all_at_thread_exit_p+0x0000004c3ba3) #3 boost::thread::thread(void (&)()) (notify_all_at_thread_exit_p+0x0000004c2f8b) #4 main (notify_all_at_thread_exit_p+0x0000004c0903) SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::atomic_increment(int _Atomic*) ================== No errors detected. ThreadSanitizer: reported 6 warnings EXIT STATUS: 66 }}} " viboes viboes 11499 windows - exception lock_error while intensive locking/unlocking of shared_mutex on many threads thread To Be Determined Bugs 2015-07-25T23:07:06Z 2016-08-15T17:59:25Z " {{{ #include ""stdafx.h"" #include #include #include #include #include #include using MutexT = boost::shared_mutex; using ReaderLockT = std::lock_guard; using WriterLockT = std::shared_lock; MutexT gMutex; std::atomic running = true; long reads = 0; void read() { while (running) { ReaderLockT lock(gMutex); std::this_thread::yield(); ++reads; } } int main() { using namespace std; vector threads; for (int i = 0; i < 256; ++i) { threads.emplace_back(thread(read)); } string str; getline(std::cin, str); running = false; for (auto& thread : threads) { thread.join(); } return 0; } }}} " andrew maclean viboes 11550 Solaris - boost::call_once issues thread To Be Determined Bugs 2015-08-18T10:46:34Z 2015-09-23T22:23:06Z "I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I get the following error messages: {{{ ""libs/thread/src/pthread/thread.cpp"", line 144: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""libs/thread/src/pthread/thread.cpp"", line 150: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""libs/context/src/posix/stack_traits.cpp"", line 58: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)"" and ""boost::call_once(boost::once_flag&, void(*)(unsigned long*), unsigned long*)"". ""libs/context/src/posix/stack_traits.cpp"", line 66: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(&)(rlimit*), rlimit*&&)"" and ""boost::call_once(boost::once_flag&, void(*)(rlimit*), rlimit*)"". ""libs/coroutine/src/posix/stack_traits.cpp"", line 56: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)"" and ""boost::call_once(boost::once_flag&, void(*)(unsigned long*), unsigned long*)"". ""libs/coroutine/src/posix/stack_traits.cpp"", line 64: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(&)(rlimit*), rlimit*&&)"" and ""boost::call_once(boost::once_flag&, void(*)(rlimit*), rlimit*)"". ""./boost/thread/once.hpp"", line 38: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(*)()&)"". ""./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp"", line 145: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""./boost/spirit/home/classic/phoenix/closures.hpp"", line 427: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""./boost/thread/once.hpp"", line 38: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(*)()&)"". ""./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp"", line 145: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""./boost/thread/once.hpp"", line 38: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(*)()&)"". ""./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp"", line 145: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""./boost/spirit/home/classic/phoenix/closures.hpp"", line 427: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""./boost/thread/once.hpp"", line 38: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(*)()&)"". ""./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp"", line 145: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". ""./boost/thread/once.hpp"", line 38: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(*)()&)"". ""./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp"", line 145: Error: Overloading ambiguity between ""boost::call_once(boost::once_flag&, void(*)())"" and ""boost::call_once(boost::once_flag&, void(&)())"". }}} I'm not 100% sure whether these are compiler issues or Boost compiler configuration issues thus I decided to raise this ticket. " lcarreon@… viboes 12104 windows - Visual Studio 2015 Update 2 RC gives out warning C4191 in thread_primitive.hpp thread To Be Determined Bugs 2016-03-30T22:21:21Z 2017-09-16T16:48:44Z " {{{ thread/win32/thread_primitives.hpp(312): warning C4191: 'type cast': unsafe conversion from 'boost::detail::win32::farproc_t' to 'boost::detail::win32::detail::gettickcount64_t' }}} Calling this function through the result pointer may cause your program to fail" Shane Mathews (oneZero Financial Systems) viboes 12773 WINDOWS- Boost thread 1.63.0 strict aliasing warnings thread To Be Determined Bugs 2017-01-19T13:34:42Z 2017-11-14T20:54:51Z "I'm cross-compiling boost on Linux, having 32-bit mingw64 as a target. I'm still seeing strict aliasing complaints on boost 1.63.0 thread/win32/shared_mutex.hpp. As gcc 6 has even stricter aliasing rules, I'm afraid that these may be harmful, so I came up with the attached patch - which is ugly, but works. " alexandre.nunes@… viboes 12795 thread library - thread_specific_ptr documentation gives obsolete recomendation thread To Be Determined Bugs 2017-01-27T09:37:42Z 2017-11-14T20:43:42Z "thread_specific_ptr documentation says ''Though compilers often provide this facility in the form of extensions to the declaration syntax (such as _declspec(thread) or thread annotations on static or namespace-scope variable declarations), such support is non-portable, and is often limited in some way, such as only supporting POD types.'' Now as we have portable '''thread_local''' in current compilers, it should be prefered to use '''thread_local''', since thread_specific_ptr has known performance limitation." Oleksandr Guteniev viboes 5947 Use CLOCK_PROCESS_CPUTIME_ID on platform providing them chrono To Be Determined Feature Requests 2011-09-27T11:30:41Z 2012-06-03T14:11:46Z "The posix implementation of process real cpu clock uses the times() function. The resolution is better if we use ::clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &ts ); on platforms for which the CLOCK_PROCESS_CPUTIME_ID is supported. " viboes viboes 7333 Provide User-defined Literals for chrono durations on compilers supporting them chrono To Be Determined Feature Requests 2012-09-06T04:13:35Z 2012-09-08T06:46:29Z boost::chrono::duration suffixes h, min, s, ms, us, ns in namespace boost::suffixes::chrono viboes viboes 7586 Add a testable_mutex thread Feature Requests 2012-10-28T19:22:13Z 2014-09-05T06:11:32Z "Based on Associate Mutexes with Data to Prevent Races, By Herb Sutter, May 13, 2010 - http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3 ""Make our mutex testable if it isn't already. Many mutex services (including boost::mutex) don't provide a way to ask, ""Do I already hold a lock on this mutex?"" Sometimes it is needed to know if a method like is_held to be available. This wrapper associates an arbitrary lockable type with a thread id that stores the ID of the thread that currently holds the lockable. The thread id initially holds an invalid value that means no threads own the mutex. When we acquire a lock, we set the thread id; and when we release a lock, we reset it back to its default no id state.""" viboes viboes 7589 Add polymorphic lockables thread Feature Requests 2012-10-28T19:43:12Z 2014-09-05T06:11:43Z "Mutex are generic classes that work well when generic programming. Sometimes, in a OOP context, it is useful to be able to use polymorphically any model of a lockable. A poly_lockable class that defines the lockable interface could be added as well as an poly_lockable_adapter to make any Lockable inherit from poly_lockable." viboes viboes 7595 Implement interruptible threads on top of non-interruptible threads thread To Be Determined Feature Requests 2012-10-28T20:05:07Z 2012-10-28T20:06:01Z "Once we will be able to disable thread interruption it would be great if we can provide interruptible threads on top of non-interruptible threads so that the user don't pay for what they don't use, but has yet a mechanism that allows work with interruptible and non-interruptible threads on the same executable. See #7594 Allow to disallow thread interruptions" viboes viboes 7629 "Implement the algorithm deadlock detection ""lockdep""" thread To Be Determined Feature Requests 2012-11-02T16:24:53Z 2012-11-04T00:28:06Z "Implement the algorithm deadlock detection ""lockdep"" (http://ceph.com/dev-notes/lockdep-for-pthreads/)" anonymous viboes 8094 hierarchical_mutex for lock hierarchies (to avoid deadlocks) thread To Be Determined Feature Requests 2013-02-17T21:24:36Z 2014-10-26T20:41:49Z "It would be great if boost::thread could be extended with a ""hierarchical"" mutex to facilitate lock hierarchies. Lock hierarchies is a construct that associates mutexes with software layer numbers, and enforces the application to only lock ""downwards"" in the software hierarchy [1]. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing. An example draft implementation is attached. The attachment also includes a BOOST_THREAD_LOCAL work-around for missing ""thread_local"" support that should probably be moved to more neutral ground. [1] http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163" Fredrik Orderud viboes 8273 Add externally locked streams thread Feature Requests 2013-03-11T07:21:19Z 2014-09-05T06:11:53Z "Based on N3354: C++ Stream Mutexes http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3354.html add thread safe streams that gets its protecting mutex externally instead of internally as in the proposal so that several streams can share the same protecting mutex. This will be useful to take in account coherency when working with cout and cin." viboes viboes 8514 Async: Add a thread_pool executor with work stealing. thread To Be Determined Feature Requests 2013-04-28T20:57:06Z 2013-04-30T22:49:57Z See #8513 for the basic thread_pool interface viboes viboes 8517 Async: Add a variadic shared_future::then thread To Be Determined Feature Requests 2013-04-28T21:07:05Z 2013-05-28T19:09:38Z " {{{ template shared_future::type...> future::then(S&, F&& func ...); }}} " viboes viboes 9588 Add a parallel_invoke algorithm. thread To Be Determined Feature Requests 2014-01-18T10:53:12Z 2014-01-21T18:03:46Z "Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_invoke algorithm. The main difference is that the algorithm could take an Executor as parameter." viboes viboes 9589 Add a parallel_sort algorithm. thread To Be Determined Feature Requests 2014-01-18T10:53:57Z 2014-01-21T18:03:55Z "Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_sort algorithm. The main difference is that the algorithm could take an Executor as parameter." viboes viboes 9590 Add a parallel_reduce algorithm. thread To Be Determined Feature Requests 2014-01-18T10:55:43Z 2014-01-21T18:04:06Z " Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_reduce algorithm. The main difference is that the algorithm could take an Executor as parameter. " viboes viboes 9591 Add a parallel_for algorithm. thread To Be Determined Feature Requests 2014-01-18T10:58:07Z 2014-01-22T12:07:39Z " Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for algorithm. The main difference is that the algorithm could take an Executor as parameter. " viboes viboes 9592 Add a parallel_for_each algorithm thread To Be Determined Feature Requests 2014-01-18T11:01:52Z 2014-01-21T18:04:27Z "Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for_each algorithm. The main difference is that the algorithm could take an Executor as parameter. " viboes viboes 9599 Add a parallel_transform algorithm thread To Be Determined Feature Requests 2014-01-22T12:03:31Z 2014-01-22T12:06:12Z " Base on http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_transform algorithm. The main difference is that the algorithm could take an Executor as parameter. " viboes viboes 10299 Add queue iterators thread To Be Determined Feature Requests 2014-08-02T15:10:58Z 2014-08-02T15:11:12Z As for http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators add queue iterators. viboes viboes 10301 Add shared_queue_front and shared_queue_back thread To Be Determined Feature Requests 2014-08-02T15:20:52Z 2014-08-02T15:41:52Z Based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#Managed add shared_queue_front and shared_queue_back. viboes viboes 10316 Thread: add subscription operator if the value provide it. thread To Be Determined Feature Requests 2014-08-06T08:51:17Z 2014-09-29T08:19:58Z "I would like to be able to do {{{ typedef boost::synchronized_value< boost::container::flat_map > ValueIndex; ValueIndex index; index[0] = 1; }}} and would expect that last line to be equivalent to {{{ auto locked_index = index.synchronize(); (*locked_index)[0] = 1; }}} I'm not totally sure it's possible to do but it would help." mjklaim@… viboes 10424 future/shared_future::then() in case of continuation return an invalid future thread To Be Determined Feature Requests 2014-08-30T08:50:59Z 2014-09-28T22:40:41Z "Add this behavior to future/shared_future::then() - In case of implicit unwrapping, the validity of the `future` returned from `then` cannot be established until after the completion of the functor passed into `then`. In such case, the resulting `future` becomes ready with an exception of type `future_error`, with an error code of `future_errc::broken_promise`. " viboes viboes 10550 Implicit unwrapping from then() calls thread To Be Determined Feature Requests 2014-09-27T16:00:45Z 2014-09-28T22:41:28Z Follows the Fundamental TS wording for ::then() function. viboes viboes 10551 Make futures returned by then()/when_all/when_any don't block. thread To Be Determined Feature Requests 2014-09-27T16:25:20Z 2014-09-27T16:26:27Z " Follows the Fundamental TS wording for ::then()/ when_all/when_any functions. " viboes viboes 10610 Add unwrap shared_future constructor thread To Be Determined Feature Requests 2014-10-05T10:17:57Z 2014-10-05T10:21:25Z "Following N4123, add unwrap shared_future constructor See also https://github.com/cplusplus/concurrency_ts/issues/58 {{{ shared_future(future>&& rhs) noexcept; Effects: Constructs a shared_future object from the shared state referred to by rhs. The shared_future becomes ready when one of the following occurs: Both the outer future and the inner shared_future are ready. The shared_future inherits the value or the exception from the inner shared_future. The outer future is ready but the inner shared_future is invalid. The shared_future gets an exception of type std::future_error, with an error code of std::future_errc::broken_promise. Postconditions: valid() returns the same value as rhs.valid() prior to the constructor invocation. valid() == true. rhs.valid() == false. }}} " viboes viboes 10878 boost::thread::attributes -> no non-variadic-support thread To Be Determined Feature Requests 2014-12-16T22:12:16Z 2016-09-02T20:55:32Z "In terms of applying thread attributes right now the documentation describes only this signature: template thread(attributes& attrs, Callable func); but this does not work when variadics are not supported (leading to error: type 'boost::thread_attributes' does not provide a call operator) Nevertheless, this temporaray way works out: thread(attributes& attrs, boost::bind(Callable func)); " a.carot@… viboes 10914 Add a future::notify_when_ready function thread To Be Determined Feature Requests 2015-01-07T02:46:17Z 2015-01-07T02:46:29Z This function should help to implement a generic wait_for_any on models of Future. viboes viboes 10915 Change wait_for_any to work on models of Future. thread To Be Determined Feature Requests 2015-01-07T02:47:53Z 2015-01-07T02:48:00Z Using notify_when_any implement a generic wait_for_any on models of Future. viboes viboes 10916 Change wait_for_all to work on models of Future. thread To Be Determined Feature Requests 2015-01-07T02:48:57Z 2015-01-07T02:49:06Z viboes viboes 10966 packaged_task::reset should not reuse the shared state to conform to C++11 thread To Be Determined Feature Requests 2015-01-24T09:51:16Z 2015-01-26T07:33:49Z "The standard says {{{ void reset(); Effects: as if *this = packaged_task(std::move(f)), where f is the task stored in *this. [ Note: This constructs a new shared state for *this. The old state is abandoned (30.6.4). — end note ] Throws: — bad_alloc if memory for the new shared state could not be allocated. — any exception thrown by the move constructor of the task stored in the shared state. — future_error with an error condition of no_state if *this has no shared state. }}} Boost.Thread reuse the shared state. {{{ Effects: Reset the state of the packaged_task so that it can be called again. }}} " viboes viboes 11041 Add no_unit to duration_style. chrono To Be Determined Feature Requests 2015-02-17T19:08:27Z 2016-03-05T09:32:21Z "When using Chrono I/O V2, currently there's no easy way to specify that only the numeric value of a duration without the unit should be output to a stream (equivalent of duration unit pattern ""%v""). It would be useful to add a new enumerator, say 'no_unit', to duration_style enumeration, and a corresponding stream manipulator (e.g. 'no_unit_format')." rkawulak viboes 11052 Make all executors copyable pointing to a shared context thread To Be Determined Feature Requests 2015-02-20T14:08:23Z 2015-09-29T20:18:58Z "Ensuring that the lifetime of an executor is longer than the continuations could be hard for the user. In particular, the tests add a sleep for to ensure it. This is not robust enough. " viboes viboes 11264 Add variadic lock_guard of Lockables thread To Be Determined Feature Requests 2015-05-03T12:56:45Z 2015-05-14T15:59:40Z "lock_guard works with BasicLockable. In order the variadic version to avoid deadlock, it can work only with Lockable, as the use of lock forces it." viboes viboes 11552 Warning from chrono that could helpfully be suppressed ratio Boost 1.60.0 Feature Requests 2015-08-18T10:58:32Z 2017-08-22T20:51:01Z " Boost.Chrono is emitting warnings with GCC (5.1.0) that cannot be suppressed even using the following cxxflags in the user jamfile {{{ gcc:-Wno-deprecated-declarations gcc:-Wno-long-long gcc:-ftrack-macro-expansion=0 # Suppress note: in expansion of macro }}} and they are repeated on every compilation which is quite annoying when reading the log file. For example: {{{ gcc.compile.c++ ..\..\..\bin.v2\libs\timer\build\gcc-mingw-5.1.0\debug\link-static\auto_timers_construction.o In file included from C:/Program Files/mingw-w64/x86_64-5.1.0-win32-seh-rt_v4-rev0/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0/include/stdint.h:9:0, from ..\..\../boost/cstdint.hpp:60, from ..\..\../boost/ratio/config.hpp:13, from ..\..\../boost/ratio/ratio.hpp:35, from ..\..\../boost/chrono/duration.hpp:41, from ..\..\../boost/chrono/chrono.hpp:11, from ..\..\../boost/timer/timer.hpp:14, from ..\..\..\libs\timer\src\auto_timers_construction.cpp:23: ..\..\../boost/chrono/system_clocks.hpp:77:111: warning: use of C++11 long long integer constant [-Wlong-long] # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::duration > ^ ..\..\../boost/chrono/system_clocks.hpp:77:90: note: in expansion of macro 'BOOST_RATIO_INTMAX_C' # define BOOST_SYSTEM_CLOCK_DURATION boost::chrono::duration > }}} and more... It would be nice if the user would not see these (spurious?) warnings." Paul A. Bristow viboes 11717 Associate an Executor used to launch the continuation to a promise/packaged_task constructor. thread To Be Determined Feature Requests 2015-10-10T14:55:30Z 2015-10-11T18:16:01Z "Currently we have `async` function that constructs futures associated to an `Executor`. The `then()` member function should use this executor to launch the continuation. See #11716. But futures can also have other sources, as e.g. a `promise` or a `packaged_task`. This paper proposes the addition of `Executor` aware constructors for `promise` and `packaged_task` so that the continuation on the associated future make use of this executor. We propose to: * Add `promise::promise(Executor&)` Executor aware constructor. * Add `packaged_task::packaged_task(Executor&)` Executor aware constructor. " viboes viboes 11773 Extract close/closed to a more specific shutdonw-executor interface. thread To Be Determined Feature Requests 2015-10-29T13:11:31Z 2015-10-29T13:13:45Z viboes viboes 11774 Extract try_executing_one, reschedule_until to a more specific reentrant executor interface. thread To Be Determined Feature Requests 2015-10-29T13:12:35Z 2015-10-29T13:12:58Z viboes viboes 12416 Windows: shared_mutex::state_data exceptions thrown in synthetic tests thread To Be Determined Feature Requests 2016-08-28T23:21:13Z 2017-02-19T10:53:41Z "Hi, My name is Tomer Gal. We have created synthetic benchmarks in which we create many threads. This causes shared_mutex to throw an exception when it has more than 2047 waiting threads due to the following limits: struct state_data { unsigned shared_count:11, shared_waiting:11, exclusive:1, upgrade:1, exclusive_waiting:7, exclusive_waiting_blocked:1; Obviously, creating more than 2047 threads waiting for a lock is too much for 'normal' code... however, the boost library shouldn't be the limiting factor for such a usage in my opinion. The state_data is currently limited to the size of(long) which is 32 bits, and it looks like it could be increased to 64 bits. Could this be fixed? Regards, Tomer Gal, CTO at OpTeamizer " Tomer Gal viboes 11619 Chrono V2 IO - format tags 'unsupported'? chrono To Be Determined Support Requests 2015-09-04T20:24:43Z 2015-09-11T17:02:24Z "http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.io.ios_state_hpp.sag.set_time_fmt table 6.3 on the page linked above describes format tags to be used with IO. Several are listed as unsupported. There is no explanation of what 'unsupported' means. Does it mean a format string with one of those tags will cause an exception? Will the format tag be ignored? Will the entire format string fail to work? Will interation over the string stop before or after the 'unsupported' tag? More explanation would be helpful here." steve.hickman@… viboes 11633 chrono IO V1 may throw bad_cast chrono To Be Determined Support Requests 2015-09-09T14:59:45Z 2017-08-28T05:19:54Z "I had occurences of chrono io throwing bad_cast exceptions, which lead to backtraces like this one: {{{ #0 0x00007ffff54fda30 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #1 0x00007ffff554f2a2 in std::__throw_bad_cast() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #2 0x00007ffff2289bab in std::use_facet > (__loc=...) at /usr/include/c++/4.8/bits/locale_classes.tcc:137 #3 0x00007ffff2288c61 in boost::chrono::operator<< , boost::rational, boost::ratio<1l, 1l> > (os=..., d=...) at /home/sbarthelemy/.local/share/qi/toolchains/linux64/boost/include/boost/chrono/io_v1/chrono_io.hpp:210 }}} I think the attached minimal example reproduces the issue. Here the compile & run log using boost 1.58 {{{ $ make clean && make test rm -f src/*.o src/chrono_io clang++ -std=c++11 -c -g -fPIC -Iinclude -I/usr/include -o src/chrono_io.o src/chrono_io.cc clang++ -std=c++11 -rdynamic -Lsrc -o src/chrono_io src/chrono_io.o -lboost_chrono -lboost_system -lpthread -L/usr/lib/x86_64-linux-gnu LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu ./src/chrono_io terminate called after throwing an instance of 'std::bad_cast' what(): std::bad_cast Aborted (core dumped) Makefile:13: recipe for target 'test' failed make: *** [test] Error 13 }}} Here is the code around boost/include/boost/chrono/io_v1/chrono_io.hpp:210 {{{ template std::basic_ostream& operator<<(std::basic_ostream& os, const duration& d) { typedef duration_punct Facet; std::locale loc = os.getloc(); if (!std::has_facet(loc)) os.imbue(std::locale(loc, new Facet)); const Facet& f = std::use_facet(os.getloc()); //<<<<<<< line210, throw here return os << d.count() << ' ' << f.template name(d.count()); } }}} maybe we could avoid calling os.getloc() again at line 210 to avoid the race?" Sébastien Barthélémy viboes 11639 document std's vs boost's chrono::steady_clock system-wideness discrepancy chrono To Be Determined Support Requests 2015-09-10T08:20:34Z 2015-10-25T23:49:58Z "boost doc states that its steady_clock is system-wide, in doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.cpp0x.system_clocks_hpp.steady_clock {{{ steady_clock class provides access to the system-wide steady clock. The current time can be obtained by calling steady_clock::now(). There is no fixed relationship between values returned by steady_clock::now() and wall-clock time. }}} As far as I know, the C++11 standard does not make this requirement. It would be good to highlight this discrepancy in the doc, especially since the doc ""Included on the C++11 Recommendation"" section let's you think that boost's chrono and std's chrono are interchangeable." Sébastien Barthélémy viboes 13408 Boost Library Possible memory Leak thread To Be Determined Support Requests 2018-01-19T14:30:46Z 2018-04-14T06:37:19Z "Hi, We have been using Boost library in the project. I've made analysis by using Valgrind tool to be able to find possible memory leaks. According to the result, there is a memory leak in Boost library. {{{ ==7535== 24 bytes in 1 blocks are still reachable in loss record 2 of 6 ==7535== at 0x4C2B0E0: operator new(unsigned long) (vg_replace_malloc.c:324) ==7535== by 0x4E430A3: boost::detail::make_external_thread_data() (in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0) ==7535== by 0x4E433DB: boost::detail::add_new_tss_node(void const*, boost::shared_ptr, 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, void*, bool) (in /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0) ==7535== by 0x54CAC0C: boost::log::v2_mt_posix::core::add_thread_attribute(boost::log::v2_mt_posix::attribute_name const&, boost::log::v2_mt_posix::attribute const&) }}} It seems like the allocated memory is not deallocated, so it causes memory leak. Here is the definition of relevant event ; {{{ thread_data_base* make_external_thread_data() { thread_data_base* const me(detail::heap_new()); me->self.reset(me); set_current_thread_data(me); return me; } thread_data_base* get_or_make_current_thread_data() { thread_data_base* current_thread_data(get_current_thread_data()); if(!current_thread_data) { current_thread_data=make_external_thread_data(); } return current_thread_data; } }}} I've made some research if there is any post which states that this event causes memory leak, but could not find any. Is there any fix for the problem stated above? If there is any, could you please state the relevant patch ? Thanks in advance, Kind Regards " anonymous viboes 13599 condition_variable::timed_wait never returns thread To Be Determined Support Requests 2018-06-14T03:04:33Z 2018-09-11T21:29:43Z "boost::condition_variable::timed_wait never returns if compiled with -DBOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC. this_thread::sleep and thread::timed_join exhibit the same problem, but both these functions are documented as deprecated. However condition_variable::timed_wait is not documented as deprecated. This can be worked around by using condition_variable::wait_for. The following simple test program demonstrates the problem in that it hangs forever. Removing the #define makes it return after one second. {{{ #define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC #include #include int main( int argc, char* argv[] ) { boost::condition_variable cv; boost::mutex m; boost::mutex::scoped_lock lock( m ); cv.timed_wait( lock, boost::posix_time::seconds( 1 ) ); std::cout << ""wait_for has returned"" << std::endl; return 0; } }}} " steven.cook@… viboes 11252 make make_ready_future more efficient thread To Be Determined Tasks 2015-04-29T23:37:32Z 2015-05-03T20:55:53Z this function should be more efficient using a specific shared_state constructor. viboes viboes 11798 Implementation of boost::shared_mutex on POSIX is suboptimal thread To Be Determined Tasks 2015-11-16T12:52:52Z 2017-12-13T02:08:35Z "The current (as of boost 1.59) implementation of boost::shared_mutex for 'pthread' is pretty suboptimal as it's using a heavyweight mutex to guard the internal mutex state. This is more evident when shared locks are used to guard state whose access concurrency is high, due to contention on the mutex state lock (in these cases, the shared mutex is effectively exclusive). In comparison, the 'win32' implementation uses lightweight spinlocks underneath. There are a couple options to fix this for 'pthread', e.g. using a spinlock or leveraging pthreads_rwlock. I'm happy to provide with an initial patch for this." alex@… viboes 12433 Make use of make_shared whenever possible in future.hpp thread To Be Determined Tasks 2016-09-03T18:06:36Z 2016-09-03T18:06:47Z Even if boost::make_shared is not aware of Boost.Move there are a lot of places in future.hpp where make shared could be used and improve the performances. viboes vladimir_prus 2438 gcc.jam sets LD_LIBRARY_PATH which breaks FreeBSD build build Boost 1.42.0 Bugs 2008-10-27T16:57:06Z 2010-01-11T17:10:44Z "In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to: /usr/bin:/usr/lib:/usr/lib32:/usr/lib64 Couple of points: - /usr/bin (?) :D - /usr/lib on FreeBSD does not contain major number libs so most if not all binaries will not pick up anything from here - /usr/lib32 on FreeBSD DOES CONTAIN major number libs so if you are building on 32-bit this will work, HOWEVER if you are building 64-bit then this will cause failures - /usr/lib64 does not exist on FreeBSD (I believe this is a Linux thing) Based on the comments within gcc.jam I FEEL as do some other people (see thread reference) that if bjam is *really* going to rely on rtld then it should do so by NOT setting anything to LD_LIBRARY_PATH which many have pointed out is only to be used when the standard search path is not enough. Setting this PATH is very dangerous and for 99% of the build cases, rtld does the right thing. Thread: http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html If it is decided to set LD_LIBRARY_PATH then we need to make this OS specific and unset it for FreeBSD (or minimally add back /lib which Steven pointed out in the above thread is probably not the right solution given LD_LIBRARY_PATH's semantics)." pisymbol@… vladimir_prus 2732 boost bjam install respects umask build Boost 1.38.0 Bugs 2009-02-05T21:19:52Z 2009-11-10T08:17:53Z "Using bjam to install boost 1.37 the install procedure respects the current umask of the user. This is not the expected behaviour. Other software install routines usually make sure to set the file modes explicitly (for example they use the unix program 'install'). Thus, if you have a umask like 0077 you have by default a boost installation which is only readable by yourself. Again, no other 'make install' or such command behaves like this. I used this command line to install boost under Solaris 10: ./tools/jam/src/bin.solaris/bjam -sICU_PATH=/usr --user-config=user-config.jam --with-test --with-program_options address-model=64 -d3 --prefix=myprefix install " gsauthof@… vladimir_prus 3550 specify toolset to bootstrap.bat Building Boost Boost 1.46.0 Bugs 2009-10-23T15:14:14Z 2010-12-19T22:05:03Z "Hi, calling ""bootstrap.bat"" results in successful compilation of boost_1_40_0\tools\jam\src\bin.ntx86_64\bjam.exe but this is not where the bootstrap.bat expects it to be, as it only supports x86 as it seems. BTW: tools\jam\src\build.bat somehow finds my VS2010beta and uses that for compilation (although I'd like it to use my production VS9) and it seems I have no control of telling ""bootstrap.bat"" to use a custom toolset (this is supported by build.bat) cheers Chris" bielow@… vladimir_prus 3564 bjam creates wrong library name when toolset choice is invalid Building Boost Boost 1.42.0 Bugs 2009-10-26T15:25:57Z 2009-11-10T07:11:18Z "Hi, I just called boost using ""bjam address-model=64 install --with-math link=static toolset=msvc-9 variant=debug"" which creates libraries without any VC version number: --> libboost_math_tr1l-vc-mt-gd-1_40.lib which should be --> libboost_math_tr1l-vc90-mt-gd-1_40.lib This leads to auto-linking errors. The documentation at multiple points simply states that appending the MSVC version number to the toolset will work, however the correct syntax for the call is: ""toolset=msvc-9.0"" and not ""toolset=msvc-9"" The documentation for valid numbers is somewhat hidden as well (http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.msvc). At least the toolset docu (http://www.boost.org/doc/libs/1_40_0/more/getting_started/windows.html#identify-your-toolset) could use the above link! So, is it possible to introduce white-lists for the toolset options to avoid this kind of error?! " bielow@… vladimir_prus 1094 Finding the correct library to link (feature request for pkg-config support)h build Boost 1.42.0 Feature Requests 2007-07-16T17:41:27Z 2018-06-06T12:34:57Z "This bug report is a feature request for the addition of pkg-config support to Boost, in order to provide a simple, reliable, platform-independent mechanism for discovering if the Boost libraries are installed, what they are called, where they are installed, and how to link with them. This is currently not possible to achieve. A detailed rationale and an example for how to implement this follow. I make use of several Boost libraries in my schroot program (svn://svn.debian.org/svn/buildd-tools/trunk/schroot). This project, like many, utilises GNU Autoconf and Automake for its build system. I need to determine how to link with the Boost libraries in order to build the programs in the project. This is an issue for many projects which want to link with a Boost library. Note that calling bjam is not a possibility here; it may not be installed, and most projects are not using bjam, especially if boost is just one of many libraries being used. To illustrate my problem: ls -l /usr/lib/libboost_regex-*.so /usr/lib/libboost_program_options-*.so lrwxrwxrwx 1 root root 45 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-1_34.so -> libboost_program_options-gcc41-1_34.so.1.34.0 lrwxrwxrwx 1 root root 48 2007-07-08 11:48 /usr/lib/libboost_program_options-gcc41-mt-1_34.so -> libboost_program_options-gcc41-mt-1_34.so.1.34.0 lrwxrwxrwx 1 root root 41 2007-07-08 11:48 /usr/lib/libboost_program_options-mt.so -> libboost_program_options-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 38 2007-07-08 11:48 /usr/lib/libboost_program_options-st.so -> libboost_program_options-gcc41-1_34.so lrwxrwxrwx 1 root root 35 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-1_34.so -> libboost_regex-gcc41-1_34.so.1.34.0 lrwxrwxrwx 1 root root 38 2007-07-08 11:47 /usr/lib/libboost_regex-gcc41-mt-1_34.so -> libboost_regex-gcc41-mt-1_34.so.1.34.0 lrwxrwxrwx 1 root root 31 2007-07-08 11:47 /usr/lib/libboost_regex-mt.so -> libboost_regex-gcc41-mt-1_34.so lrwxrwxrwx 1 root root 28 2007-07-08 11:47 /usr/lib/libboost_regex-st.so -> libboost_regex-gcc41-1_34.so Unlike every other library on my system, the Boost libraries have the compiler (gcc41) and threading model (mt|st) and so on embedded *in the library name*. This makes it impossible to discover in an automatic fashion. Since my project is free software anyone can download and build, I don't know what the compiler/toolchain will be, let alone what abbreviation Boost has chosen for it. I expect that Autoconf will set up such things appropriately; my code is relatively compiler-agnostic, but I can't predict the Boost library names without help. The only means I have are the libboost_program_options-mt.so, libboost_program_options-st.so (and so on for all the libraries) symbolic links which the Debian maintainer has helpfully provided. However, these are not portable, and are so not a good solution. They are, however, the only available solution at the moment. To further show the problem I am having, this is part of my configure.ac Autoconf template: ---configure.ac---- AC_CHECK_HEADERS([tr1/memory]) AC_CHECK_HEADERS([boost/shared_ptr.hpp],, [ if test $ac_cv_header_tr1_memory = yes; then : else AC_MSG_ERROR([Boost.shared_ptr (Boost C++ Libraries) is not installed, but is required by schroot]) fi]) AC_CHECK_HEADERS([tr1/tuple]) AC_CHECK_HEADERS([boost/tuple/tuple.hpp],, [ if test $ac_cv_header_tr1_memory = yes; then : else AC_MSG_ERROR([Boost.Tuple (Boost C++ Libraries) is not installed, but is required by schroot]) fi]) AC_CHECK_HEADERS([boost/format.hpp],, [AC_MSG_ERROR([Boost.Format (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/program_options.hpp],, [AC_MSG_ERROR([Boost.Program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_CHECK_HEADERS([boost/type_traits.hpp],, [AC_MSG_ERROR([Boost.TypeTraits (Boost C++ Libraries) is not installed, but is required by schroot])]) AC_MSG_CHECKING([for boost::program_options::variables_map in -lboost_program_options-st]) saved_ldflags=""${LDFLAGS}"" LDFLAGS=""${LDFLAGS} -lboost_program_options-st"" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [boost::program_options::variables_map::variables_map dummy()])], [AC_MSG_RESULT([yes]) BOOST_LIBS=""${BOOST_LIBS} -lboost_program_options-st""], [AC_MSG_RESULT([no]) AC_MSG_FAILURE([libboost_program_options (Boost C++ Libraries) is not installed, but is required by schroot])]) LDFLAGS=""${saved_ldflags}"" AC_MSG_CHECKING([for boost::program_options::options_description::options() in -lboost_program_options-st]) saved_ldflags=""${LDFLAGS}"" LDFLAGS=""${LDFLAGS} -lboost_program_options-st"" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [boost::program_options::options_description testgrp(""test group""); bool notused = testgrp.options().empty(); ])], [AC_MSG_RESULT([yes]) BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS=""current""], [AC_MSG_RESULT([no]) BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS=""old""]) LDFLAGS=""${saved_ldflags}"" AH_TEMPLATE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, [Set if boost::program_options::options_description::options() is not available]) if test ""$BOOST_PROGRAM_OPTIONS_DESCRIPTION_METHODS"" = ""old""; then AC_DEFINE(BOOST_PROGRAM_OPTIONS_DESCRIPTION_OLD, 1) fi AC_MSG_CHECKING([for boost::regex in -lboost_regex-st]) saved_ldflags=""${LDFLAGS}"" LDFLAGS=""${LDFLAGS} -lboost_regex-st"" AC_LINK_IFELSE([AC_LANG_PROGRAM([#include ], [boost::regex(""^foo[bar]$"")])], [AC_MSG_RESULT([yes]) BOOST_LIBS=""${BOOST_LIBS} -lboost_regex-st""], [AC_MSG_RESULT([no]) AC_MSG_FAILURE([libboost_regex (Boost C++ Libraries) is not installed, but is required by schroot])]) LDFLAGS=""${saved_ldflags}"" AC_SUBST([BOOST_LIBS]) ---configure.ac---- As you can see, that's quite a bit of complexity. It also includes code to work around a backwards compatibility issue in Boost.Program_options. However, it needs to know the library name in order to link the test code, and I'm still needing to use a non-standard name in order to do that. It would be great if Boost would provide a mechanism to allow such discovery. Such a mechanism already exists, and is called ""pkg-config"". By installing a small file in LIBDIR/pkgconfig for each Boost library, the pkg-config tool or PKG_CHECK_MODULES Autoconf macro may be used to query this information. As an example: ---- boost-regex-mt.pc ---- prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: boost-regex-mt Description: Boost C++ Regular Expression Library (multi-threaded) Version: 1.34.0 Libs: -L${libdir} -lboost_regex-gcc41-mt-1_34 Libs.private: -licui18n -licuuc -lrt -lm Cflags: -I${includedir} -pthread ---- boost-regex-mt.pc ---- You can generate this from a template: ---- boost-regex-mt.pc.in ---- prefix=PREFIX exec_prefix=EPREFIX libdir=LIBDIR includedir=INCLUDEDIR Name: boost-regex-mt Description: Boost Regular Expression Library (multi-threaded) Version: VERSION Libs: -L${libdir} LIBRARY_NAME Libs.private: LIBRARY_DEPENDENCIES [for static linking] Cflags: -I${includedir} THREAD_OPTIONS_FOR_COMPILER ---- boost-regex-mt.pc.in ---- where the capitalised names are where you would substitute in the system- and compiler-specific options. It looks like bjam could probably make this a single rule all libraries could make use of. For such a setup, all that configure script above could be mostly reduced to PKG_CHECK_MODULES([boost-regex-st]) PKG_CHECK_MODULES([boost-program-options-st]) I don't know how bjam works, but I do this with Autoconf as a file generated by config.status, but it could also be generated by make with a simple sed command. I guess you could do the bjam equivalent, whatever that might be. I have had a look at the sources to try to implement this, but I am afraid I lack the bjam expertise to do it. You may find much more detailed discussion of these issues at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424038 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424666 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425264 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428419 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350539 Some of these are due to Debian-specific issues (a change to the symlink name), but the root cause is the inability to identify the Boost library names in an automated fashion. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail." rleigh@… vladimir_prus 2746 Please allow specifying the library SONAME in Jamroot build Boost 1.39.0 Feature Requests 2009-02-11T02:11:36Z 2009-11-09T18:03:08Z "In working on packaging the luabind library (which utilizes Boost.Jam) for Debian, I found the way that the library SONAME is passed to the linker is not ""correct."" It seems like since the SONAME is something that should ideally be managed by the library developer, it would be good if Boost.Jam allowed the library SONAME to be specified in the Jamroot file (for operating systems that have a notion of a SONAME). Here is the related thread from the luabind-user mailing list: http://news.gmane.org/find-root.php?message_id=%3c20090131051842.GA15718%40connexer.com%3e Thanks to some help from volodya in IRC, we worked up the patch from the first message in the above thread. However, I think that some sort of configuration variable, that if set, allowed specifying the SONAME would be better. In the absence of the SONAME being specified in the Jamroot file, the current behavior could be kept as default." roberto@…